CRLF (%0D%0A) Injection
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
バグバウンティのヒント: Intigritiにサインアップしてください。これはハッカーによって、ハッカーのために作られたプレミアムバグバウンティプラットフォームです！今日、https://go.intigriti.com/hacktricksに参加し、最大**$100,000**のバウンティを獲得し始めましょう！
CRLF
キャリッジリターン（CR）とラインフィード（LF）は、CRLFとして知られる特別な文字列で、HTTPプロトコルで行の終わりや新しい行の開始を示すために使用されます。ウェブサーバーとブラウザは、HTTPヘッダーとレスポンスのボディを区別するためにCRLFを使用します。これらの文字は、ApacheやMicrosoft IISなど、さまざまなウェブサーバータイプのHTTP/1.1通信で普遍的に使用されています。
CRLFインジェクション脆弱性
CRLFインジェクションは、ユーザー提供の入力にCRおよびLF文字を挿入することを含みます。このアクションは、サーバー、アプリケーション、またはユーザーを誤解させ、挿入されたシーケンスを1つのレスポンスの終わりと別のレスポンスの開始として解釈させます。これらの文字は本質的に有害ではありませんが、その誤用はHTTPレスポンスの分割やその他の悪意のある活動につながる可能性があります。
例: ログファイルにおけるCRLFインジェクション
管理パネルのログファイルがIP - 時間 - 訪問パスという形式に従っていると仮定します。典型的なエントリは次のようになります:
攻撃者はCRLFインジェクションを利用してこのログを操作できます。HTTPリクエストにCRLF文字を注入することで、攻撃者は出力ストリームを変更し、ログエントリを偽造できます。例えば、注入されたシーケンスはログエントリを次のように変えるかもしれません:
ここで、%0d と %0a は CR と LF の URL エンコード形式を表します。攻撃後、ログは誤解を招く形で表示されるでしょう:
攻撃者は、ローカルホスト（サーバー環境内で通常信頼されるエンティティ）がアクションを実行したかのように見せかけることで、悪意のある活動を隠蔽します。サーバーは、%0d%0aで始まるクエリの部分を単一のパラメータとして解釈し、restrictedactionパラメータは別の入力として解析されます。操作されたクエリは、正当な管理コマンドを効果的に模倣します：/index.php?page=home&restrictedaction=edit
HTTPレスポンス分割
説明
HTTPレスポンス分割は、攻撃者がHTTPレスポンスの構造を悪用することで発生するセキュリティ脆弱性です。この構造は、特定の文字列、キャリッジリターン（CR）とラインフィード（LF）を使用してヘッダーとボディを分離します。これらは合わせてCRLFと呼ばれます。攻撃者がレスポンスヘッダーにCRLFシーケンスを挿入することに成功すると、以降のレスポンスコンテンツを効果的に操作できます。この種の操作は、特にクロスサイトスクリプティング（XSS）などの深刻なセキュリティ問題を引き起こす可能性があります。
HTTPレスポンス分割によるXSS
アプリケーションは次のようなカスタムヘッダーを設定します：
X-Custom-Header: UserInputアプリケーションは、クエリパラメータ「user_input」から
UserInputの値を取得します。適切な入力検証とエンコーディングが欠如しているシナリオでは、攻撃者はCRLFシーケンスを含むペイロードを作成し、その後に悪意のあるコンテンツを追加できます。攻撃者は特別に作成された'user_input'を持つURLを作成します：
?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
このURLでは、
%0d%0a%0d%0aはCRLFCRLFのURLエンコード形式です。これにより、サーバーはCRLFシーケンスを挿入し、以降の部分をレスポンスボディとして扱うように仕向けます。
サーバーは攻撃者の入力をレスポンスヘッダーに反映させ、悪意のあるスクリプトがレスポンスボディの一部としてブラウザによって解釈される意図しないレスポンス構造を引き起こします。
リダイレクトにつながるHTTPレスポンス分割の例
ブラウザへ：
サーバーは次のヘッダーで応答します：
他の例: (から https://www.acunetix.com/websitesecurity/crlf-injection/)
In URL Path
URLパスの中にペイロードを送信して、サーバーからのレスポンスを制御できます（こちらの例）：
Check more examples in:
HTTPヘッダーインジェクション
HTTPヘッダーインジェクションは、CRLF（キャリッジリターンとラインフィード）インジェクションを通じて悪用されることが多く、攻撃者がHTTPヘッダーを挿入することを可能にします。これにより、XSS（クロスサイトスクリプティング）フィルターやSOP（同一生成元ポリシー）などのセキュリティメカニズムが損なわれ、CSRFトークンなどの機密データへの不正アクセスや、クッキーの植え付けを通じたユーザーセッションの操作につながる可能性があります。
HTTPヘッダーインジェクションを介したCORSの悪用
攻撃者はHTTPヘッダーを注入してCORS（クロスオリジンリソースシェアリング）を有効にし、SOPによって課せられた制限を回避することができます。この侵害により、悪意のあるオリジンからのスクリプトが異なるオリジンのリソースと相互作用し、保護されたデータにアクセスする可能性があります。
CRLFを介した SSRF と HTTPリクエストインジェクション
CRLFインジェクションは、まったく新しいHTTPリクエストを作成して注入するために利用できます。これの顕著な例は、PHPのSoapClientクラスの脆弱性で、特にuser_agentパラメータ内にあります。このパラメータを操作することで、攻撃者は追加のヘッダーやボディコンテンツを挿入したり、まったく新しいHTTPリクエストを注入したりすることができます。以下は、この悪用を示すPHPの例です：
ヘッダーインジェクションによるリクエストスモグリング
この技術と潜在的な問題についての詳細は、元のソースを確認してください。
初期リクエストに応答した後にバックエンドが接続を維持することを保証するために、重要なヘッダーをインジェクトできます：
その後、2回目のリクエストを指定できます。このシナリオは通常、HTTP request smugglingを含み、これはサーバーがインジェクション後に追加した余分なヘッダーやボディ要素がさまざまなセキュリティの脆弱性につながる技術です。
悪用:
悪意のあるプレフィックスインジェクション: この方法は、悪意のあるプレフィックスを指定することで次のユーザーのリクエストやウェブキャッシュを汚染することを含みます。これの例は次のとおりです：
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回目のリクエストを形成するプレフィックスを作成することを含みます。これによりレスポンスキューの汚染が引き起こされる可能性があります。例は次のとおりです：
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インジェクション
Memcacheはクリアテキストプロトコルを使用するキー-バリューストアです。詳細は次のリンクを参照してください：
11211 - Pentesting Memcache完全な情報は 元の文書 をお読みください
プラットフォームがHTTPリクエストからデータを取得し、サニタイズせずにメモリキャッシュサーバーへのリクエストを実行している場合、攻撃者はこの動作を悪用して新しいメモリキャッシュコマンドを注入することができます。
たとえば、最初に発見された脆弱性では、キャッシュキーがユーザーが接続すべきIPとポートを返すために使用され、攻撃者はメモリキャッシュコマンドを注入してキャッシュを汚染し、被害者の詳細（ユーザー名とパスワードを含む）を攻撃者のサーバーに送信することができました：
さらに、研究者たちは、攻撃者のIPとポートを、攻撃者が知らないユーザーに送信するためにメモリキャッシュのレスポンスをデシンクさせることができることも発見しました：
WebアプリケーションにおけるCRLF / HTTPヘッダーインジェクションの防止方法
WebアプリケーションにおけるCRLF（キャリッジリターンとラインフィード）またはHTTPヘッダーインジェクションのリスクを軽減するために、以下の戦略が推奨されます：
レスポンスヘッダーに直接ユーザー入力を避ける: 最も安全なアプローチは、ユーザー提供の入力を直接レスポンスヘッダーに組み込まないことです。
特殊文字をエンコードする: 直接ユーザー入力を避けることが不可能な場合は、CR（キャリッジリターン）やLF（ラインフィード）などの特殊文字をエンコードするための関数を使用することを確認してください。この実践により、CRLFインジェクションの可能性が防止されます。
プログラミング言語を更新する: Webアプリケーションで使用されるプログラミング言語を定期的に最新バージョンに更新します。HTTPヘッダーを設定する関数内でCRおよびLF文字の注入を本質的に許可しないバージョンを選択してください。
CHEATSHEET
自動ツール
ブルートフォース検出リスト
参考文献
バグバウンティのヒント: ハッカーによって、ハッカーのために作られたプレミアム バグバウンティプラットフォーム Intigritiに サインアップ しましょう！ https://go.intigriti.com/hacktricks に今日参加し、最大 $100,000 の報酬を得始めましょう！
