Hello there, ('ω')ノ
🎯 目的：異なるシステム間の解釈の違いを突く
- フロントエンドは1つ目のHostを参照
- バックエンドは最後のHostを使用
- 中継サーバーとアプリケーションで動作が異なる
このようなズレをうまく利用できれば、ルーティングと検証をすり抜けて悪意ある処理を実行できる可能性があります。
1️⃣ Hostヘッダーを重複させる
GET /example HTTP/1.1 Host: vulnerable-website.com Host: attacker.com
💡 期待される挙動
- フロントエンドが最初のHostを使用：ターゲットのアプリケーションにリクエストが到達
- バックエンドが最後のHostを使用：悪意あるデータが処理に使われる
2️⃣ 絶対URLを使う
GET https://vulnerable-website.com/ HTTP/1.1 Host: attacker.com
💡 なぜ効くの？
- リクエストラインとHostヘッダーの矛盾を引き起こす
- 特にリバースプロキシやCDNがURL全体を見てルーティングする設定の場合に有効
3️⃣ 行の折り返し（インデント）を使う
GET /example HTTP/1.1
Host: attacker.com
Host: vulnerable-website.com
💡 解釈の違いを突く
- インデントを「折り返し行」扱いするサーバーもある
- インデントを無視して「前のヘッダーと統合」するケースもある
これにより、フロントエンドでは無害に見えるが、バックエンドでは意図しない動作になる可能性があります。
🔧 その他のテクニック
- HTTPリクエストスマグリングと組み合わせたHostヘッダー攻撃
X-Forwarded-HostやForwardedヘッダーを使ったオーバーライド
✅ チェックリスト
| テクニック | 攻撃意図 |
|---|---|
| 重複したHostを送る | ルーティングと処理の不一致を引き起こす |
| 絶対URLでリクエスト | URL解釈のずれを誘発 |
| 行の折り返しで偽装 | バリデーション回避 |
| 他のヘッダーで上書き | 中間サーバーの設定ミスを狙う |
Best regards, (^^ゞ
