HTTPホストヘッダーインジェクションとは？パスワードリセット汚染・キャッシュポイズニングの仕組みと対策を解説

「パスワードリセットのリンクが届いた。でもURLのドメインが正規のものじゃない」

もしそんな報告が社内から上がってきたら、HTTPホストヘッダーインジェクションが原因の可能性があります。

HTTPの ヘッダーは、クライアントが「どのサーバーに接続したいか」を伝える基本的なヘッダーです。しかし多くのWebアプリケーションが、このHostヘッダーの値を検証せずにURL生成などの処理に使ってしまっています。攻撃者はこの仕組みを悪用して、パスワードリセットメールに攻撃者のドメインへ誘導するリンクを仕込む「パスワードリセット汚染」や、CDNやリバースプロキシのキャッシュに不正なコンテンツを蓄積させる「Webキャッシュポイズニング」といった攻撃を実行します。

この記事では、Hostヘッダーの仕組みから始め、攻撃者がどのような手口で悪用するか、そして現場のエンジニア・情シス担当者が実践できる防御手順を解説します。

HTTPホストヘッダーとは？なぜ危険なのか

HTTP/1.1のリクエストには、必ず ヘッダーが含まれます。クライアントはこのヘッダーで「どのドメインのリソースを求めているか」をサーバーに伝えます。

例えば にアクセスした際のリクエストは次のようになります。

GET /reset-password HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Cookie: session=abc123

この ヘッダーの値は、通常はブラウザがアクセス先のドメインから自動的に設定します。しかし コマンドやBurp Suiteなどのプロキシツールを使えば、攻撃者は自由に書き換えることができます。

問題の本質は、多くのWebアプリケーションがHostヘッダーの値を「信頼できる値」として扱い、URLの動的生成に使ってしまう点です。PHPであれば 、Pythonであれば などでHostヘッダーの値を取得し、メール本文のリセットURLを組み立てるコードが散見されます。

この設計は、攻撃者が任意のドメインを埋め込んだURLを被害者に送り付けられることを意味します。

攻撃の仕組み（攻撃者視点で理解する）

1. パスワードリセット汚染（Password Reset Poisoning）

最も実害につながりやすい攻撃パターンです。アカウント乗っ取りに直結するため、重大度は高に分類されます。

攻撃の流れを整理します。

1. 攻撃者はターゲットのメールアドレス（例: ）を把握している
2. パスワードリセットフォームに被害者のメールアドレスを入力し、Hostヘッダーを に書き換えてリクエストを送信する

POST /forgot-password HTTP/1.1
Host: evil-attacker.example
Content-Type: application/x-www-form-urlencoded

email=victim@example.com

3. サーバーがHostヘッダーを検証せずURL生成に使っていると、被害者のメールボックスに次のようなリセットリンクが届く

# 被害者のメールに届くリセットURL（攻撃者ドメインに誘導されている）
https://evil-attacker.example/reset?token=a3f9b1c2d4e5f6...

4. 被害者がリンクをクリックすると、攻撃者のサーバーにリセットトークンが送信される
5. 攻撃者はそのトークンを使って正規のリセットエンドポイントを呼び出し、被害者のパスワードを変更してアカウントを乗っ取る

メールアドレスさえ知っていれば実行できる攻撃です。大量のアカウントを標的にした自動化も容易で、リスト型攻撃と組み合わせると被害が拡大します。

2. Webキャッシュポイズニング（Web Cache Poisoning）

CDNやリバースプロキシ（Nginx・Varnish・CloudFrontなど）を利用している環境で特に注意が必要です。

アプリケーションがHostヘッダーをレスポンス本文に含める場合（エラーページ・リダイレクト先URL・ナビゲーションリンクなど）、攻撃者が細工したHostヘッダーを持つリクエストを送ると、汚染されたコンテンツがキャッシュに蓄積されることがあります。その後、同じURLにアクセスした正規ユーザーにも汚染されたレスポンスが返され、フィッシングページへ誘導するリンクが表示される可能性があります。

エラーページに「ログインはこちら」というリンクが動的に生成されていて、その際にHostヘッダーが使われていると、キャッシュに攻撃者ドメインへのリンクが記録されます。不特定多数のユーザーが被害を受ける点が、パスワードリセット汚染と異なる危険性です。

3. HTTPリダイレクトの操作

HTTPからHTTPSへのリダイレクトや、ログイン後の遷移先URLを組み立てる際にHostヘッダーを使っているアプリケーションも影響を受けます。

# 攻撃者が送るリクエスト
GET /login HTTP/1.1
Host: evil-attacker.example

# 脆弱なアプリのレスポンス（HostをそのままLocationに使用）
HTTP/1.1 301 Moved Permanently
Location: https://evil-attacker.example/login

ブラウザはこのレスポンスに従い、攻撃者のサイトへリダイレクトします。ユーザーは正規のURLにアクセスしたつもりでも、気づかないうちにフィッシングサイトへ誘導されます。

4. 内部仮想ホストへのアクセス（バーチャルホストブルートフォース）

複数のドメインを1台のサーバーで運用するバーチャルホスト構成では、本来外部から到達できないはずの内部仮想ホストに対して、Hostヘッダーを書き換えることでアクセスできる場合があります。開発環境・管理画面・内部APIが外部ネットワークからアクセス可能になるリスクがあるため、バーチャルホスト構成の設計と合わせて注意が必要です。

具体的な防御手順

1. フレームワークの許可ホスト（ALLOWED_HOSTS）を設定する

最も基本的かつ効果的な対策です。使用しているWebフレームワークが提供する「許可するHostヘッダーのリスト」を必ず設定します。

# Django (settings.py)
# 許可するHostヘッダーを明示的に列挙する（'*' は本番環境で絶対に禁止）
ALLOWED_HOSTS = [
    'www.example.com',
    'app.example.com',
]

// Laravel (.env) - APP_URLに正規ドメインを設定する
APP_URL=https://www.example.com

// TrustHostsミドルウェア (App/Http/Middleware/TrustHosts.php)
protected function hosts()
{
    return [
        'www.example.com',
        'app.example.com',
        // サブドメイン一括許可はリスクがあるため慎重に検討する
    ];
}

Rails であれば 、Node.js/Go を使った独自実装であればリクエストのHostヘッダーをホワイトリストと照合するミドルウェアを実装します。「許可するホストを設定する」という発想自体が抜けているケースが多いため、まずここから着手してください。

2. URLの動的生成にHostヘッダーを使わない

パスワードリセットメール・メール内リンク・リダイレクト先URLを組み立てる際は、Hostヘッダーの値を直接使うコードを排除します。

# Bad: Hostヘッダーをそのまま使用（脆弱）
reset_url = "https://" + request.headers.get("Host") + "/reset?token=" + token

# Good: 設定ファイルの静的ドメインを使用（安全）
from django.conf import settings
reset_url = "https://" + settings.APP_DOMAIN + "/reset?token=" + token

// Bad: ['HTTP_HOST'] を直接使用（脆弱）
 = "https://" . ['HTTP_HOST'] . "/reset?token=" . ;

// Good: 設定値を使用（安全）
 = "https://" . config('app.domain') . "/reset?token=" . ;

とくにメール送信処理はデバッグしにくく、問題が起きても気づきにくいため、コードレビュー時に や をURL文字列に連結していないかチェックするルールを設けることをお勧めします。

3. NginxでバックエンドへのHostヘッダーを固定する

Nginxをリバースプロキシとして使っている場合、バックエンドアプリに転送する際のHostヘッダーをサーバー側で固定します。

# Nginxの設定例
server {
    listen 443 ssl;
    server_name www.example.com;

    location / {
        # （クライアント送信値）ではなく（Nginx設定値）を使う
        proxy_set_header Host ;

        # X-Forwarded-Hostを外部から受け取らないよう除去する
        proxy_set_header X-Forwarded-Host "";

        proxy_pass http://backend;
    }
}

は「クライアントが送ってきたHostヘッダーの値そのまま」であり、攻撃者が制御できます。 はNginx設定ファイルで定義した正規のホスト名であり、外部から書き換えられません。この1行の違いが重要です。

4. ヘッダーの扱いを明確にする

ロードバランサーやCDNが使う ヘッダーも、Hostヘッダーと同様の攻撃に使われます。信頼できる内部プロキシからのリクエストにのみ付与されるよう制御し、外部から直接操作できないようにします。フレームワークによっては を優先的にURL生成に使う実装もあるため、どちらが実際に使われているかを確認してください。

中小企業でも今日からできること

HostヘッダーインジェクションはWebアプリのコードレベルの問題ですが、情シス担当者が確認・要求できる点もあります。

・パスワードリセットメールのURLを実際に確認する: 自社の主要なWebシステムのパスワードリセット機能を使い、届いたメールのリンクURLが正規のドメインになっているかチェックするだけで、脆弱性の有無を手軽に点検できます
・許可ホスト設定の要件を開発委託契約に追加する: 「フレームワークのALLOWED_HOSTSまたは同等の機能で、許可するHostヘッダーを明示的に設定すること」を受け入れテスト項目に加えてください。（全許可）になっていないかを受け入れ時に必ず確認します
・Nginxのproxy_set_header Host の設定を確認する: インフラを管理している場合は ではなく を使っているかチェックします。変更は数分で完了します
・X-Forwarded-Host除去設定を追加する: 外部からこのヘッダーを受け取らないよう をNginx設定に追加してください

LinuxサーバーのNginxセキュリティ設定については、姉妹サイトLinuxMaster.JPでも実践的な設定例を解説しています。プロキシ周りのセキュリティ設計にお役立てください。

よくある誤解と注意点

【誤解1】HTTPSにしていれば防げる

TLS（HTTPS）はHostヘッダーを含むリクエスト全体を暗号化しますが、攻撃者が自分で送るリクエストのHostヘッダーは攻撃者自身が自由に設定できます。HTTPSはHostヘッダーインジェクションの対策にはなりません。

【誤解2】WAFで検知・防御できる

Hostヘッダーインジェクションは正規のHTTPリクエスト形式に準拠しているため、WAFによる自動検知が困難なケースが多いです。根本的な対策はアプリケーションコードとインフラ設定の両面での実装です。WAFはあくまで多層防御の一要素と捉えてください。

【誤解3】ポートを含むHostヘッダーは対策済みのことが多い

Hostヘッダーにはポート番号が含まれる場合があります（例: ）。ホワイトリストを実装している場合でも、ポートあり・なしのバリエーションを漏らさず照合できているかを確認してください。

【注意】インターナルAPIにも注意が必要

外部公開サービスだけでなく、社内向けのWebアプリケーションや管理画面も同様の脆弱性を持ち得ます。「外部に公開していないから大丈夫」という思い込みは禁物です。VPNやバーチャルホスト設定の不備と組み合わさると、内部システムへの侵入経路になります。

Hostヘッダーインジェクション対策チェックリスト

本記事のまとめ

HTTPホストヘッダーインジェクションは「Hostヘッダーを信頼してはいけない」という原則を守っていないことで発生します。被害はパスワードリセット汚染によるアカウント乗っ取りから、Webキャッシュポイズニングによる不特定多数への影響まで幅広く、現実のインシデントでも繰り返し観測されている攻撃手法です。

・根本対策は「ホワイトリスト」と「静的ドメイン使用」の2点: フレームワークの許可ホスト設定を正しく構成し、URL生成には設定ファイルの静的ドメインを使う
・パスワードリセット機能は最優先の点検対象: 実際にリセットメールを送り、URLドメインを確認するだけで問題を発見できる
・インフラ設定も合わせて確認する: Nginxの と 除去の2点はすぐ実施できる
・情シスの観点では受け入れ要件への組み込みが有効: 開発仕様書・受け入れテストにHostヘッダー検証要件を追加する

Webアプリケーションのセキュリティはコードとインフラ設定の両輪です。フレームワークが提供するセキュリティ機能を正しく使い、「デフォルトで安全」な構成を維持することが、日常業務の中で攻撃リスクを下げる最も現実的なアプローチです。