Hello there, ('ω')ノ
1. なぜ「ズレ」が起きるのか？
ウェブアプリは多層構造になっています。 ユーザー → フロントエンド（ロードバランサ・プロキシ） → バックエンド（アプリケーションサーバー）
このとき、リクエストサイズの解釈に使うヘッダが異なると「食い違い」が発生します。
- フロントエンド：Transfer-Encoding を優先（チャンク分割方式で解釈）
- バックエンド：Content-Length を優先（固定長で解釈）
攻撃者はこの差を利用して、**本来検知されないリクエストを「すり抜けて密輸」**できるのです。
2. 攻撃のストーリー（ハッカーの視点）
ステップ1：攻撃環境の準備
Burp Suite などのプロキシツールを使って、リクエストを自由に改造できる環境を用意します。 → なぜ？ 攻撃の基本は「リクエストを手でいじれるかどうか」です。
ステップ2：ターゲット探し
ロードバランサやWAF（Web Application Firewall）が前段にあり、後段にアプリケーションサーバーがある構成を狙います。 → なぜ？ 二重解釈が発生するのは「多層構造」の場合のみだからです。
ステップ3：ズレを発生させるリクエストを作成
両方のヘッダを含む怪しいリクエストを送ります。
POST / HTTP/1.1 Host: target.com Content-Length: 4 Transfer-Encoding: chunked a2 POST /malicious-path HTTP/1.1 Host: attacker-domain.com Content-Length: 15 x=1 0
- フロントエンドは Transfer-Encoding: chunked を見て「最初のチャンク」だけを処理
- バックエンドは Content-Length: 4 を見て「残りのリクエスト」を別リクエストとして解釈
結果：本来通らないはずの /malicious-path リクエストが密輸成功
3. 自動化と確認
攻撃を効率化するために、Burp Suite の Turbo Intruder を使って何度も送信します。 → なぜ？ サーバーのズレは毎回確実に出るとは限らないため、繰り返し試行が必要です。
成功すると：
- 予期せぬ 404エラー が出る
- レスポンス中に 攻撃者のドメイン が混ざる
これが「すり抜けた証拠」となります。
4. どんな被害が起こるか？
成功すれば、攻撃者は次のようなことが可能になります。
- データ窃取：他ユーザーのリクエストに割り込み、認証情報やCookieを盗む
- セッションハイジャック：被害者になりすましてログイン状態を乗っ取る
- ストア型XSS：悪意あるスクリプトを保存させて持続的に利用者へ配布
- Web改ざん：正常なレスポンスを攻撃者が差し替え
つまり「サーバー間のズレ」を突くだけで、最上流からユーザー体験を操作できるのです。
5. \$750バウンティの理由
報告者は、密輸に成功した証拠として 攻撃者のドメインがアプリのレスポンス中に現れることを確認しました。 これは「外部からアプリの動作を制御できる」重大リスクと判断され、報酬が支払われたのです。
まとめ：学ぶべきハッカー的思考法
攻撃者の基本的な考え方はシンプルです。
- 入力がどこを通っているか？（フロントとバックで解釈は違うか？）
- そのズレを利用して何を差し込めるか？（隠しリクエスト・Cookie盗み・スクリプト挿入）
- 結果をどう観測するか？（レスポンス中に痕跡を探す）
この思考を持つと、単なる「仕組みの暗記」ではなく、攻撃者がどのように弱点を見つけ出すのかが理解できるようになります。
Best regards, (^^ゞ
