diff --git a/src/pentesting-web/crlf-0d-0a.md b/src/pentesting-web/crlf-0d-0a.md index 2aeae8025..ddc038ff9 100644 --- a/src/pentesting-web/crlf-0d-0a.md +++ b/src/pentesting-web/crlf-0d-0a.md @@ -4,11 +4,11 @@ ### CRLF -キャリッジリターン (CR) とラインフィード (LF) は、CRLF として知られる特別な文字列で、HTTP プロトコルで行の終わりや新しい行の開始を示すために使用されます。ウェブサーバーとブラウザは、HTTP ヘッダーとレスポンスのボディを区別するために CRLF を使用します。これらの文字は、Apache や Microsoft IIS などのさまざまなウェブサーバータイプで、HTTP/1.1 通信において普遍的に使用されています。 +キャリッジリターン (CR) とラインフィード (LF) は、CRLF として知られる特別な文字列で、HTTP プロトコルで行の終わりや新しい行の開始を示すために使用されます。ウェブサーバーとブラウザは、HTTP ヘッダーとレスポンスのボディを区別するために CRLF を使用します。これらの文字は、Apache や Microsoft IIS など、さまざまなウェブサーバータイプの HTTP/1.1 通信で普遍的に使用されています。 ### CRLF インジェクション脆弱性 -CRLF インジェクションは、ユーザー提供の入力に CR および LF 文字を挿入することを含みます。この行為は、サーバー、アプリケーション、またはユーザーを誤解させ、挿入されたシーケンスを1つのレスポンスの終わりと別のレスポンスの開始として解釈させます。これらの文字は本質的に有害ではありませんが、その誤用は HTTP レスポンスの分割やその他の悪意のある活動につながる可能性があります。 +CRLF インジェクションは、ユーザー提供の入力に CR および LF 文字を挿入することを含みます。このアクションは、サーバー、アプリケーション、またはユーザーを誤解させ、挿入されたシーケンスを1つのレスポンスの終わりと別のレスポンスの開始として解釈させます。これらの文字は本質的に有害ではありませんが、その誤用は HTTP レスポンスの分割やその他の悪意のある活動につながる可能性があります。 ### 例: ログファイルにおける CRLF インジェクション @@ -18,7 +18,7 @@ CRLF インジェクションは、ユーザー提供の入力に CR および L ``` 123.123.123.123 - 08:15 - /index.php?page=home ``` -攻撃者はCRLFインジェクションを利用してこのログを操作できます。HTTPリクエストにCRLF文字を注入することで、攻撃者は出力ストリームを変更し、ログエントリを偽造することができます。例えば、注入されたシーケンスはログエントリを次のように変換するかもしれません: +攻撃者はCRLFインジェクションを利用してこのログを操作できます。HTTPリクエストにCRLF文字を注入することで、攻撃者は出力ストリームを変更し、ログエントリを偽造することができます。例えば、注入されたシーケンスはログエントリを次のように変えるかもしれません: ``` /index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit ``` @@ -40,7 +40,7 @@ HTTPレスポンス分割は、攻撃者がHTTPレスポンスの構造を悪用 #### HTTPレスポンス分割によるXSS 1. アプリケーションは次のようなカスタムヘッダーを設定します：`X-Custom-Header: UserInput` -2. アプリケーションは、クエリパラメータ「user_input」から`UserInput`の値を取得します。適切な入力検証とエンコーディングが欠如しているシナリオでは、攻撃者はCRLFシーケンスを含むペイロードを作成し、その後に悪意のあるコンテンツを追加できます。 +2. アプリケーションは、クエリパラメータ「user_input」から`UserInput`の値を取得します。適切な入力検証とエンコーディングが欠如しているシナリオでは、攻撃者はCRLFシーケンスを含むペイロードを作成し、その後に悪意のあるコンテンツを続けることができます。 3. 攻撃者は特別に作成された'user_input'を持つURLを作成します：`?user_input=Value%0d%0a%0d%0a` - このURLでは、`%0d%0a%0d%0a`はCRLFCRLFのURLエンコード形式です。これにより、サーバーはCRLFシーケンスを挿入し、以降の部分をレスポンスボディとして扱うように仕向けます。 4. サーバーは攻撃者の入力をレスポンスヘッダーに反映させ、悪意のあるスクリプトがレスポンスボディの一部としてブラウザによって解釈される意図しないレスポンス構造を引き起こします。 @@ -74,7 +74,7 @@ https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf. ### HTTPヘッダーインジェクション -HTTPヘッダーインジェクションは、CRLF（キャリッジリターンとラインフィード）インジェクションを通じて悪用されることが多く、攻撃者がHTTPヘッダーを挿入することを可能にします。これにより、XSS（クロスサイトスクリプティング）フィルターやSOP（同一生成元ポリシー）などのセキュリティメカニズムが脅かされ、CSRFトークンなどの機密データへの不正アクセスや、クッキーの植え付けを通じたユーザーセッションの操作につながる可能性があります。 +HTTPヘッダーインジェクションは、CRLF（キャリッジリターンとラインフィード）インジェクションを通じて悪用されることが多く、攻撃者がHTTPヘッダーを挿入することを可能にします。これにより、XSS（クロスサイトスクリプティング）フィルターやSOP（同一生成元ポリシー）などのセキュリティメカニズムが損なわれ、CSRFトークンなどの機密データへの不正アクセスや、クッキーの植え付けを通じたユーザーセッションの操作につながる可能性があります。 #### HTTPヘッダーインジェクションを介したCORSの悪用 @@ -82,7 +82,7 @@ HTTPヘッダーインジェクションは、CRLF（キャリッジリターン #### CRLFを介したSSRFおよびHTTPリクエストインジェクション -CRLFインジェクションは、まったく新しいHTTPリクエストを作成して挿入するために利用できます。これの顕著な例は、PHPの`SoapClient`クラスの脆弱性であり、特に`user_agent`パラメータ内にあります。このパラメータを操作することで、攻撃者は追加のヘッダーやボディコンテンツを挿入したり、まったく新しいHTTPリクエストを注入したりすることができます。以下は、この悪用を示すPHPの例です: +CRLFインジェクションは、まったく新しいHTTPリクエストを作成して挿入するために利用できます。これに関する顕著な例は、PHPの`SoapClient`クラスの脆弱性であり、特に`user_agent`パラメータ内にあります。このパラメータを操作することで、攻撃者は追加のヘッダーやボディコンテンツを挿入したり、まったく新しいHTTPリクエストを注入したりすることができます。以下は、この悪用を示すPHPの例です: ```php $target = 'http://127.0.0.1:9090/test'; $post_string = 'variable=post value'; @@ -107,7 +107,7 @@ array( # Put a netcat listener on port 9090 $client->__soapCall("test", []); ``` -### ヘッダーインジェクションによるリクエストスモグリング +### ヘッダーインジェクションによるリクエストスムージング この技術と潜在的な問題についての詳細は、[**元のソースを確認してください**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)。 @@ -115,7 +115,7 @@ $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](http-request-smuggling/)に関係しており、サーバーがインジェクション後に追加したヘッダーやボディ要素がさまざまなセキュリティの脆弱性につながる技術です。 +その後、2回目のリクエストを指定できます。このシナリオは通常、[HTTP request smuggling](http-request-smuggling/)に関係しており、サーバーがインジェクション後に追加した余分なヘッダーやボディ要素がさまざまなセキュリティの脆弱性につながる技術です。 **悪用:** @@ -137,9 +137,9 @@ Memcacheは**クリアテキストプロトコルを使用するキー-バリュ **完全な情報は**[ **元の文書を読んでください**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/) -プラットフォームが**HTTPリクエストからデータを取得し、それをサニタイズせずに**メモリキャッシュサーバーへの**リクエスト**を実行する場合、攻撃者はこの動作を悪用して**新しいメモリキャッシュコマンドを注入**することができます。 +プラットフォームが**HTTPリクエストからデータを取得し、サニタイズせずに**メモリキャッシュサーバーへの**リクエスト**を実行する場合、攻撃者はこの動作を悪用して**新しいメモリキャッシュコマンドを注入**することができます。 -例えば、最初に発見された脆弱性では、キャッシュキーがユーザーが接続すべきIPとポートを返すために使用され、攻撃者は**メモリキャッシュコマンドを注入**して**キャッシュを汚染し、被害者の詳細**（ユーザー名やパスワードを含む）を攻撃者のサーバーに送信することができました： +例えば、元々発見された脆弱性では、キャッシュキーがユーザーが接続すべきIPとポートを返すために使用され、攻撃者は**メモリキャッシュコマンドを注入**して**キャッシュを汚染し、被害者の詳細**（ユーザー名やパスワードを含む）を攻撃者のサーバーに送信することができました：
https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop
@@ -151,7 +151,7 @@ Memcacheは**クリアテキストプロトコルを使用するキー-バリュ WebアプリケーションにおけるCRLF（キャリッジリターンとラインフィード）またはHTTPヘッダーインジェクションのリスクを軽減するために、以下の戦略が推奨されます： -1. **レスポンスヘッダーに直接ユーザー入力を避ける**: 最も安全なアプローチは、ユーザー提供の入力を直接レスポンスヘッダーに組み込まないことです。 +1. **レスポンスヘッダーに直接ユーザー入力を避ける**: 最も安全なアプローチは、ユーザーが提供した入力を直接レスポンスヘッダーに組み込まないことです。 2. **特殊文字をエンコードする**: 直接ユーザー入力を避けることができない場合は、CR（キャリッジリターン）やLF（ラインフィード）などの特殊文字をエンコードするための関数を使用することを確認してください。この実践により、CRLFインジェクションの可能性が防止されます。 3. **プログラミング言語を更新する**: Webアプリケーションで使用されるプログラミング言語を定期的に最新バージョンに更新します。HTTPヘッダーを設定する関数内でCRおよびLF文字の注入を本質的に許可しないバージョンを選択してください。 @@ -179,20 +179,57 @@ WebアプリケーションにおけるCRLF（キャリッジリターンとラ • %E5%98%BC = %3C = \u563c (<) • Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test ``` +### 最近の脆弱性 (2023 – 2025) + +過去数年間で、広く使用されているサーバーおよびクライアント側コンポーネントにおいて、いくつかの高影響なCRLF/HTTPヘッダーインジェクションバグが発生しました。これらをローカルで再現し、研究することは、実際の悪用パターンを理解するための優れた方法です。 + +| 年 | コンポーネント | CVE / アドバイザリー | 根本原因 | PoC ハイライト | +|------|-----------|---------------|------------|---------------| +| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | `AddHeader()` ヘルパーがCR/LFをサニタイズせず、RestSharpがバックエンドサービス内でHTTPクライアントとして使用される際に複数のリクエストヘッダーを構築できるようにしました。下流のシステムはSSRFやリクエストスモグリングを強制される可能性があります。 | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` | +| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | インターフェースメソッドのヘッダー属性がリクエストにそのままコピーされました。`%0d%0a`を埋め込むことで、攻撃者は任意のヘッダーや、Refitがサーバー側のワーカージョブで使用される際に第二のリクエストを追加することができました。 | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` | +| 2023 | Apache APISIX Dashboard | **GHSA-4h3j-f5x9-r6x3** | ユーザー提供の`redirect`パラメータがエンコードされずに`Location:`ヘッダーにエコーされ、オープンリダイレクト + キャッシュポイズニングを可能にしました。 | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a` | + +これらのバグは、**アプリケーションレベルのコード内**でトリガーされるため重要であり、ウェブサーバーのエッジだけではありません。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によって許可されているため、多くのリバースプロキシはそれを変更せずに転送します。 + ## 自動ツール -- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) -- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz) +* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – Goで書かれた高速アクティブスキャナー。 +* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – Unicode改行ペイロードをサポートする単語リストベースのファズァ。 +* [crlfix](https://github.com/glebarez/crlfix) – Goプログラムによって生成されたHTTPリクエストをパッチする2024ユーティリティで、内部サービスをテストするためにスタンドアロンで使用できます。 ## ブルートフォース検出リスト -- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt) +- [carlospolop/Auto_Wordlists – crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt) ## 参考文献 -- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/) -- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/) -- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning) -- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/) +- [https://www.invicti.com/blog/web-security/crlf-http-header/](https://www.invicti.com/blog/web-security/crlf-http-header/) +- [https://www.acunetix.com/websitesecurity/crlf-injection/](https://www.acunetix.com/websitesecurity/crlf-injection/) +- [https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning) +- [https://www.netsparker.com/blog/web-security/crlf-http-header/](https://www.netsparker.com/blog/web-security/crlf-http-header/) +- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302) +- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/) {{#include ../banners/hacktricks-training.md}}