CRLFインジェクション攻撃

CRLFインジェクション攻撃とは

CRLFインジェクション攻撃は、攻撃者が予期しないCRLF文字列を挿入することで発生するアプリのコーディングミスです。HTTPレスポンス分割は、CRLF文字列を用いてHTTPレスポンスヘッダーを区切ることに起因します。適切に処理されない入力が原因で、CRLF文字列の脆弱性が生じます。

攻撃者は、定められたテキストストリーム内にCRLF文字列を挿入し、アプリが予期しない、場合によっては危険な動作を引き起こすよう仕向けます。CRLFの弱点を突き、テキストストリームを分割して本来予期されない内容を追加するのです。これにより、セキュリティ突破や重大な被害が発生する可能性があります。

アプリ層では、CRLF挿入はセキュリティ上の欠陥を利用する手法です。たとえば、攻撃者は入力データを悪用し、HTTPレスポンスにおけるCRLF挿入の脆弱性を利用することが可能です。

HTTPレスポンス分割

HTTP通信においてCRLF文字列は、ひとつのヘッダーの終了と次のヘッダーの始まり、またはヘッダーの終了と本文の開始を示すために用いられます。

攻撃者は、1回のCRLF挿入で新たなヘッダーを作成できます。たとえばLocationヘッダーの場合、訪問者を別サイトに誘導することが可能です。この手法はフィッシングや破壊行為にも使われ、HTTPヘッダーインジェクションと呼ばれます。

さらに、2回連続のCRLFを挿入することでHTTPヘッダーを終了し、本来のページ本文の前に任意の内容を埋め込むことが可能です。ここにJavaScriptコードを混入させ、アプリがサーバから送られる本来の本文を無視するよう仕向ける場合もあります。これがHTTPレスポンス分割とクロスサイトスクリプティング（XSS）の連携の仕組みです。

CRLFは、以下のような不正操作に利用される場合があります:

• ‍偽のContent-Lengthヘッダーを追加: 0。これにより、アプリはこれを1つのレスポンスの終了と判断し、次のレスポンスの解析に入ります。
• ‍HTTPレスポンスを新たに作成: HTTP/1.1 200 OK。この行が別のレスポンスの始まりとなります。
• ‍偽のHTTPレスポンスヘッダーを加える: Content-TypeとしてText/htmlが指定され、これによりアプリが本文を正しく解析できるようになります。
• ‍偽のHTTPレスポンスヘッダーをさらに追加: Content-Length: 25。アプリはその後の25バイトを次のレスポンスとして処理します。

Script>alert(1)/script>をXSSで本文に追加します。この追加部分は実際に25バイトです。

アプリはContent-Lengthヘッダーにより、サーバから送られた本来の本文を無視します。

http ://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

この手法は、中間者攻撃やウェブストア攻撃にも利用され、攻撃者の内容が他の利用者に配信される恐れがあります.

HTTPヘッダーインジェクション

攻撃者はCRLF結合を利用してHTTPヘッダーを挿入し、アプリのXSS対策やその他のセキュリティ機構を回避することが可能です。有害な攻撃者は、CSRFトークンなどの機密情報を入手する恐れもあります。また、被害者のPCに悪意あるコードを配置し、ログの改ざんや未知のクロスサイト脆弱性の悪用に繋がる場合もあります。

HTTPヘッダー挿入により機密情報が漏洩する可能性があります。攻撃者がCORSを許可するHTTPヘッダーを混入させた場合、SOP（同一オリジンポリシー）により保護された資産へのJavaScriptアクセスが可能になり、異なるオリジン間の制限を突破する結果となることがあります.

CRLFインジェクションの検知方法

CRLFの混入は一見些細な問題に見えるかもしれません。なお、OWASP CRLFインジェクションは2017年のOWASP TOP 10リストには含まれておりません。しかし、CRLFインジェクションは他のアプリの脆弱性を突く、より危険な攻撃に発展する可能性があるため、注意が必要です.

幸い、ウェブ上で自動化された脆弱性スキャナーを用いることで、貴社のサイト、アプリ、あるいはAPIがCRLFインジェクション等の脆弱性に対して無防備かどうかを検査できます。デモを視聴しながら検査の実例を確認していただけます.

ほとんどのウェブシステムは通常、CRLFインジェクションの脆弱性に対処済みですが、もし未対策の場合でも、以下の対策が有効です:

• 対策1: コードを見直し、クライアントが送信した内容をHTTPストリームに直接使用しないこと.
• ‍対策2: HTTPヘッダー送信前に改行文字を除去すること.
• ‍対策3: 送信データをHTTPヘッダー上でエンコードすること。これにより、攻撃者がCRおよびLFのコードを挿入しようとしても、意味をなさなくなります.

攻撃例

例えば、CRLFインジェクションの例を見てみよう。以下は、IP、時刻、アクセス先パスが記録されるログエントリの例です:

123.123.123.123 - 08:15 -/index.php?page=home

攻撃者がHTTPリクエストにCRLF文字を混入させると、結果としてログが改ざんされ、偽のエントリが作成される恐れがあります。アプリのレスポンスも、以下のように変更される場合があります:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 -/index.php?page=home&restrictedaction=edit

ここで%0dと%0aはCRとLFのURLエンコード表現です。攻撃者が不正な文字列を挿入すると、ログは以下のように記録されます（IP - 時刻 - アクセス先パス）:

123.123.123.123 - 08:15 -/index.php?page=home&

127.0.0.1 - 08:15 -/index.php?page=home&restrictedaction=edit

攻撃者はCRLFインジェクションの脆弱性を利用して偽のエントリを作成し、行為を隠すことが可能です。この例では、攻撃者がページを取得し、レスポンスを改ざんしています.

次の状況を想定してください。攻撃者がディレクター用のパスワードにアクセスし、管理者専用のrestrictedactionパラメータを利用した場合、通常、管理者は不審な行動と判断するでしょう。しかし、リクエスト自体はlocalhostから送信されたように見えるため、一見正常なアクセスに見えます.

サーバは、%0d%0a以降の全体を1つのパラメータとして扱います。その後、restrictedactionが別のパラメータとして解析され、結果としてリクエストは以下と同等となります:

/index.php?page=home&restrictedaction=edit

CRLFインジェクションを防ぐ方法

ほとんどのウェブシステムは通常、CRLFインジェクションの脆弱性に対処済みですが、未対策の場合も容易に修正できます.

段階1: クライアントが送信した内容を直接使用しないこと

コードを再構築し、クライアント入力をHTTPストリームに直接使用しないよう注意してください.

段階2: 改行文字を除去すること

HTTPヘッダーに内容を送る前に、必ず改行文字を除去してください.

段階3: 情報をエンコードすること

HTTPヘッダーに送信する情報はエンコードしてください。攻撃者がCRおよびLFコードを挿入しようとしても、意味をなさなくなり、CRLFインジェクションの影響が大幅に低減されます.

段階4: 定期的にスキャンすること

CRLFインジェクションは、コード作成時や外部ライブラリ、モジュール、ツールの利用により発生することがあります。ウェブ脆弱性スキャナーを利用して、貴社のAPIセキュリティ状態を定期的に確認し、CRLFインジェクション攻撃を防ぐよう努めてください.