Hello there, ('ω')ノ
Hostヘッダ攻撃は、HTTPリクエストに含まれる Host ヘッダの値を偽装・改ざんすることで、
Webアプリケーションの挙動を不正に操作する攻撃です。
Webアプリは Host ヘッダを信頼して、リダイレクトやリンク生成などを行うことがあります。
このとき、攻撃者が偽のホスト名を送ると、アプリがその値を使ってしまうことがあります。
🧨 2. 何が起きるのか？（影響例）
| 攻撃内容 |
説明 |
| 🔁 オープンリダイレクト |
攻撃者のホスト名にリダイレクトされる |
| 📧 パスワードリセットリンク改ざん |
メール内URLに偽のドメインが使用される |
| 📂 キャッシュポイズニング |
異なるホストでレスポンスがキャッシュされる |
| 📬 SMTP header injection |
Host をメール内に使っている場合に影響 |
| 🧨 SSTIやXSSの起点 |
リンクを介してHTML中に埋め込まれることも |
🛠️ 3. テスト方法（基本）
Step 1️⃣：リクエストで Host ヘッダを改ざん
GET / HTTP/1.1
Host: evil.example.com
→ 本来は example.com を想定しているが、任意のホスト名でアクセスしてみる
Step 2️⃣：レスポンス・挙動の確認
- HTML内のリンク、リダイレクト先、メールなどに
Host ヘッダの値が反映されていないか
- 例：
<a href="http://evil.example.com/reset?token=...">リンク</a>
🔎 4. チェック対象となるアプリ機能
| 機能 |
備考 |
| パスワードリセット |
メールリンクが Host に依存して生成されるか？ |
| 自動リンク生成 |
アプリがURLを自動で組み立てて返す処理 |
| ログ出力 |
Hostがログに含まれているとログポイズニングの可能性 |
| サブドメイン制御 |
マルチテナント系で Host により挙動が変わる場合 |
| リダイレクト処理 |
Location: ヘッダに Host が使われているか？ |
🧪 5. テスト用ペイロード例
Hostヘッダを任意に書き換え
Host: attacker.evil.com
一部プロキシやCDN環境下で有効なヘッダも併用
X-Forwarded-Host: attacker.evil.com
X-Forwarded-Scheme: http
✅ 6. 脆弱性のサイン
| 現象 |
意味 |
| リダイレクト先が偽のホスト名になっている |
オープンリダイレクトの可能性 |
メールリンクに Host 値が反映される |
フィッシングURL作成に使える |
| HTML中に不正なホスト名が入っている |
XSSやキャッシュ汚染の起点になる |
🔐 7. 安全な実装確認ポイント
| チェック項目 |
内容 |
サーバ側で Host を固定チェックしている |
明示的に example.com のみ許可など |
Host を信頼してURL構築しない |
絶対URLを組み立てるときに注意 |
X-Forwarded-Host を信用しない |
信頼されたプロキシからのみ受け入れるべき |
アプリ内で Host に依存する処理を最小化する |
特に外部リンク生成やパス構築時 |
🧰 8. 診断ツール
| ツール名 |
用途 |
| Burp Suite |
Host ヘッダや X-Forwarded-* ヘッダの差し替えが簡単 |
| curl |
テキストベースでの素早いテスト |
| OWASP Amass / Assetnote |
DNS乗っ取りが絡む場合のスキャンに有効 |
📌 9. 実際に報告された脆弱な例（現実のケース）
- パスワードリセットメール内のリンクが
Host をもとに構築され、攻撃者が偽メールリンクを配信
- CDNが
Host をキャッシュキーに使わず、攻撃者のリクエストがキャッシュされて他者に影響
- S3バケット等でサブドメインを使ったホスト名の偽装 → リソース乗っ取り
✅ チェックリストまとめ
| チェック項目 |
✔ / ✘ |
Host を改ざんしても無視されるか？ |
✔ |
自動生成URLに Host の値が入っていないか？ |
✔ |
リダイレクトURLが Host に依存していないか？ |
✔ |
X-Forwarded-Host が無視されているか？ |
✔ |
| フィッシングに悪用できる構造がないか？ |
✔ |
Best regards, (^^ゞ
