Hell there, ('ω')ノ
記事
「I Found HTTP Request Smuggling & Got a Huge Bug Bounty! (Full Exploit Guide) 🚀」 TheIndianNetwork (2025年3月)
ねらい
この記事は、バグバウンティハンターがHTTPリクエストスマグリング（HRS）の脆弱性を発見し、セッションハイジャックやアカウント乗っ取りにつなげた手法を詳細に解説しています。 ポイントは、自動スキャナでは検出できない問題を人間の視点とテスト手法で掘り当てたところにあります。
ストーリーと実践手順
1) リコン：ターゲットを選定
- 操作：
curl -I https://target.comでレスポンスヘッダーを確認。 - 観察：
Server: nginx
X-Backend-Server: apache
→ フロントがnginx、バックエンドがApache。 * なぜ：異なるサーバ間でHTTP解析のズレが生じやすく、HRSの典型的な構成。
2) 攻撃リクエストの作成
- 操作：Burp Suiteで次のようなCL.TE攻撃リクエストを送信。
POST / HTTP/1.1
Host: target.com
Content-Length: 15
Transfer-Encoding: chunked
0
G
POST /evil HTTP/1.1
Host: target.com
Content-Length: 50
malicious_payload_here
なぜ：
- フロントサーバ（nginx） は「Content-Length」を優先して解析。
- バックエンド（Apache） は「Transfer-Encoding」を解釈。
- この解釈の違いで、隠しリクエスト（
/evil）がバックエンドに密輸される。
3) レスポンスの観察
- 結果：レスポンスに異常が発生。
HTTP/1.1 200 OK
X-Backend-Server: apache
Set-Cookie: session=smuggled_data_here;
- 意味：バックエンドが密輸されたリクエストを処理し、新しいセッションを発行している。
4) 実際の影響
確認された攻撃可能性：
- セッションハイジャック：ユーザーCookieの奪取
- 認証情報窃取：偽ログインリクエスト注入
- Webキャッシュポイズニング：キャッシュに悪意あるレスポンスを格納
- フルアカウント乗っ取り：ヘッダー改ざんによる認証突破
学びと攻撃者の視点
自動スキャナでは検知不能 → HRSは複数サーバ間の微妙なズレに依存するため、人間による観察が必須。
ヘッダの組み合わせが鍵 →
Content-LengthとTransfer-Encodingの競合が典型的な発火点。成功シグナルを見逃さない → 異常レスポンスやCookieの変化は、攻撃成立のサイン。
防御策（開発者・運用者目線）
- フロント・バックエンドのHTTP解析を統一
- HTTP/2や最新のプロキシを利用（HRSの影響を軽減）
- セキュリティヘッダー設定（キャッシュ制御・Cookie属性強化）
- WAFやリバースプロキシで異常リクエストを遮断
まとめ
攻撃者の流れはこうでした：
- リコンで異種サーバ構成を発見
- CL.TE攻撃リクエストを送信
- レスポンスに異常を確認し、セッションを密輸
- 最終的にセッションハイジャックやアカウント乗っ取りに至る
つまり、「サーバの解釈ズレ」という目に見えない境界を突くのが、HRSの本質です。
Best regards, (^^ゞ
