Hello there, ('ω')ノ
HTTPリクエスト・スマグリングとは？
HTTPリクエスト・スマグリング（HRS）は、フロントエンド（プロキシやロードバランサ）とバックエンド（アプリサーバー）がHTTPヘッダを異なるルールで解釈してしまう現象を利用します。
典型例：
- フロントエンド → Content-Length を基準に処理
- バックエンド → Transfer-Encoding: chunked を基準に処理
この食い違いによって、攻撃者は通常ならブロックされるリクエストを「すり抜け」させることができます。
1. 偵察：どこにズレが潜んでいるか？
最初のステップは、クライアント → プロキシ／ロードバランサ → バックエンド の通信フローを洗い出すことです。 攻撃者は「どのヘッダがどの層で解釈されるのか」を意識して観察します。
→ なぜ？ リクエスト処理の一貫性が崩れる場所を特定できれば、「どこに細工を仕込めるか」が見えてくるからです。
2. 不正リクエストを設計する
Burp Suite の Turbo Intruder を用いて、意図的に矛盾するリクエストを作成しました。
例：
POST /api/sessions HTTP/1.1
Host: target-domain
Content-Length: 129
Transfer-Encoding: chunked
Cookie: session=xyz
18
{"session":{"email":"test@example.com","password":"password"}}
00
GET / HTTP/1.1
Host: www.example.com
foo: x
この構造は次のように機能します：
- フロントエンドは Content-Length に従い「最初の129バイト」を処理。
- バックエンドは Transfer-Encoding: chunked を解釈し、後半のGETリクエストを新しいリクエストとして処理。
3. 攻撃の確認
通常、無効なログイン試行なら 401 Unauthorized が返るはずです。 しかし、今回はレスポンスが 200 OK でした。
→ 意味するところ： 不正なセッション開始リクエストの後ろに密輸したGETリクエストが処理されてしまったということ。
これは、確実にHRSが存在する証拠です。
4. 攻撃者が得られる可能性のある利益
HRSは単独でも危険ですが、他の脆弱性と組み合わせることで破壊力が増します。
- セッションハイジャック：正規ユーザーのセッショントークンを奪う
- 権限昇格：隠し管理機能にアクセス
- キャッシュポイズニング：悪意あるレスポンスをキャッシュに仕込み、多数の利用者に配布
- XSSへの発展：スクリプトを混入させてブラウザ側を制御
攻撃者視点では「密輸したリクエストをどこに差し込めば最大のリターンがあるか」を考えます。
5. 防御の観点（攻撃者にとって嫌な環境）
HRSを防ぐための実践的アプローチは次の通りです：
- ヘッダの解釈を統一：全サーバーが同じルールで
Content-LengthとTransfer-Encodingを処理するように設定 - 不要なヘッダを無効化：アプリで
Transfer-Encoding: chunkedが不要なら排除 - パッチ適用：ロードバランサやWebサーバーを最新状態に保つ
- WAF導入：典型的な不正リクエストパターンを検知して遮断
- リクエストバリデーション：予期せぬリクエスト形式は全て拒否
まとめ：学べるハッカー的思考
この経験から得られる重要な教訓は、**「わずかな解釈のズレが致命的な侵入口になる」**ということです。
攻撃者は常にこう考えます：
- どこでズレが起きているか？
- そのズレに何を差し込めるか？
- 差し込んだ結果をどう観測するか？
この3点を繰り返すことで、隠れたHRSを見つけ、実際に利用可能な攻撃に仕立てていきます。
Best regards, (^^ゞ
