CRLFとは何ですか?ブラウザがwebサーバーに要求を送信すると、WEBサーバーはHTTP応答ヘッダーと実際のwebサイトコンテンツ、つまり応答本文の両方を含む応答で応答します。 HTTPヘッダーとHTMLレスポンス(webサイトのコンテンツ)は、特定の特殊文字の組み合わせ、すなわちキャリッジリターンと改行で区切られています。 略してCRLFとも呼ばれます。

webサーバーはCRLFを使用して、新しいHTTPヘッダーが開始され、別のHTTPヘッダーが終了するタイミングを理解します。 CRLFは、webアプリケーションまたはユーザーに、ファイルまたはテキストブロックで新しい行が始まることを通知することもできます。 CRLF文字は標準のHTTP/1.1メッセージであるため、Apache、Microsoft IIS、その他すべてのwebサーバーを含むあらゆるタイプのwebサーバーで使用されます。

CRLFインジェクションの脆弱性とは何ですか？

CRLFインジェクションの脆弱性攻撃では、攻撃者はキャリッジリターンと改行文字の両方をユーザー入力に挿入して、サーバー、webアプリケーション、またはユーザーをだまして、オブジェクトが終了して別のオブジェクトが開始されたと考えさせます。 そのため、CRLFシーケンスは悪意のある文字ではありませんが、悪意のある意図やHTTP応答の分割などに使用できます。

webアプリケーションでのCRLFインジェクション

webアプリケーションでは、アプリケーションが単一のアイテムで何をするかに応じて、CRLFインジェクションは深刻な影響を与える可能性があります。 影響は、情報の開示からコードの実行、webアプリケーションのセキュリティの脆弱性に直接影響する可能性があります。 実際、CRLFインジェクション攻撃は、OWASP Top10リストには掲載されていませんでしたが、webアプリケーションに非常に深刻な影響を与える可能性があります。 たとえば、以下の例で説明するように、管理パネルでログファイルを操作することもできます。

ログファイル内のCRLF注入の例

以下のようなip-Time-Visited Pathの出力ストリームパターンを持つ管理パネルのログファイルを想像してみてください:

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

攻撃者がHTTPリクエストにCRLF文字を挿入することができれば、出力ストリームを変更してログエントリを偽造することができます。 彼はwebsアプリケーションからの応答を以下のようなものに変更することができます。

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

%0dと%0aは、CRとLFのurlエンコードされた形式です。 したがって、攻撃者がこれらの文字を挿入してアプリケーションが表示した後、ログエントリは次のようになります:

IP-Time-Visited Path

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

したがって、攻撃者はCRLFインジェクションの脆弱性を悪用することにより、ログファイル内のエントリを偽造して、自分の悪意 攻撃者は文字通りページのハイジャックと応答の変更を行っています。 たとえば、攻撃者が管理者パスワードを持ち、restrictedactionパラメータを実行し、管理者のみが使用できるシナリオを想像してみてください。

問題は、管理者が不明なIPがrestrictedactionパラメータを使用していることに気づいた場合、何かが間違っていることに気付くことです。 しかし、今では、コマンドがlocalhostによって発行されたように見えます（したがって、おそらく管理者のようにサーバーにアクセスできる人によって発行され

%0d%0aで始まるクエリの全部分は、サーバーによって一つのパラメータとして処理されます。 その後、別の&があり、パラメータrestrictedactionwhichはサーバーによって別のパラメータとして解析されます。 効果的には、これは次のようなクエリと同じになります:

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

HTTP応答の分割

説明

HTTP応答のヘッダーとその本文はCRLF文字で区切られているため、攻撃者はそれらを注入しようとするこ CRLFCRLFの組み合わせは、ヘッダーが終了し、本文が始まることをブラウザに伝えます。 これは、htmlコードが格納されている応答本文内にデータを書き込むことができるようになったことを意味します。 これにより、クロスサイトスクリプティングの脆弱性が発生する可能性があります。

XSSにつながるHTTP応答分割の例

カスタムヘッダーを設定するアプリケーションを想像してみてください。:

X-Your-Name: Bob

ヘッダーの値は、”name”というgetパラメータを介して設定されます。 URLエンコードが設定されておらず、値がヘッダー内に直接反映されている場合、攻撃者は上記のCRLFCRLFの組み合わせを挿入して、要求本文が開始されることをブラウ そうすれば、彼はXSSペイロードなどのデータを挿入することができます。

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

上記は、攻撃されたドメインのコンテキストでアラートウィンウ

HTTP Header Injection

Description

CRLFインジェクションを悪用することにより、攻撃者はブラウザのXSSフィルタやsame-origin-policyなどのセキュリティメカニズムを打ち負かすために使用されるHTTPヘッダーを挿入することもできます。 これにより、攻撃者はCSRFトークンのような機密情報を取得できます。 また、攻撃者のアカウントに被害者を記録したり、他の方法では開発できないクロスサイトスクリプティング(XSS)の脆弱性を悪用したりすることによ

機密データを抽出するためのHTTPヘッダー注入の例

攻撃者がCORS(Cross Origin Resource Sharing)をアクティブにするHTTPヘッダーを注入することができれば、javascriptを使用して、異なるオリジンからサイトが互いにアクセスすることを防ぐSOP(Same Origin Policy)によって保護されているリソースにアクセスすることができます。

CRLFインジェクションの脆弱性の影響

CRLFインジェクションの影響はさまざまであり、クロスサイトスクリプティングの情報開示への また、XSSフィルタや被害者のブラウザの同じオリジンポリシーなどの特定のセキュリティ制限を無効にして、悪意のある攻撃の影響を受けやすくす

WEBアプリケーションでCRLF/HTTPヘッダーの挿入を防ぐ方法

最良の防止技術は、応答ヘッダー内のユーザー入力を直接使用しないことです。 それが不可能な場合は、常にCRLF特殊文字をエンコードする関数を使用する必要があります。 もう一つの良いwebアプリケーションセキュリティのベストプラクティスは、HTTPヘッダーを設定する関数内にCRとLFを挿入できないバージョンにプログラH2>