HTTP Host ヘッダー攻撃とは？

HTTP Host ヘッダー攻撃は、攻撃者にとって一般的な手法となっており、いくつかのバリエーションがあります。攻撃の詳細と、それらがもたらす影響について深く掘り下げる前に、まずは HTTP Host ヘッダーとは何かについて説明することから始めます。

HTTP Host ヘッダーとは何ですか？

HTTP Host ヘッダーはホスト名やポート番号の情報を提供し、複数のドメインからのリクエストを処理する際、オリジンサーバーが使用するリソースを決定するのに役立つことを目的としています。

その他の Host ヘッダー

アプリケーションによっては、「X-Forwarded-Host」、「X-Host」などの追加のホストに似たヘッダーで Host ヘッダーを補完することがあります。これらの情報は、以下の攻撃の説明の一部で使用されます。これらを適切に使用しない場合、Host ヘッダーと同様な脆弱性が生じるためです。

HTTP Host ヘッダー攻撃の種類

Host ヘッダーはインターネットを使用する上で重要な要素ですが、Host ヘッダーが暗黙的に信頼されたり、追加機能に使用されたり、不適切に設定されたりすると、アプリケーションは脆弱性にさらされる可能性があります。攻撃者が Host ヘッダーにさまざまな種類のコンテンツを挿入することで、この動作を悪用し、次のようなより深刻な脆弱性を引き起こす可能性があります。

1. ホストヘッダーポイズニング

2. Web キャッシュポイズニング

3. パスワードリセットポイズニング

4. サーバーサイド・リクエスト・フォージェリ

アプリケーションが Host ヘッダーから提供される値をどのように使用しているかによっては、他のユーザー入力が安全に処理されない場合と同様に、クロスサイトスクリプティングや SQL インジェクションなどの他の攻撃を可能にする可能性もあります。こちらでは、生の SQL クエリでは Host ヘッダーを使用していないものと仮定し、より直接的な攻撃について説明します。

1. ホストヘッダーポイズニング

最も単純なケースでは、アプリケーションは Host ヘッダーの値を使用してトラフィックをリダイレクトする可能性があります。例えば、アプリケーションのログインページへのリダイレクトなどが該当します。アプリケーションが Host ヘッダーを使用してリダイレクトリンクを作成する場合、攻撃者は次の HTTP リクエストを送信できます。

GET / HTTP/1.1
Host: www.attackers-domain.example.com

そして、次のように攻撃者がコントロールするドメインにリダイレクトするレスポンスを生成します。

HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php

この攻撃自体は、標的のユーザーにこのリクエストを実行させることが難しいため、あまり有効ではありません。一方で、ホストヘッダーポイズニングは他の攻撃と組み合わせることで、その有効性を高めることができます。

2. Web キャッシュポイズニング

Web キャッシュポイズニングは、それ自体が Host ヘッダーの脆弱性ではありませんが、前述のホストヘッダーポイズニングを悪用可能にする配信メカニズムです。たとえば、アプリケーションがリダイレクトリンクを作成する際に Host ヘッダーを使用しない場合 (これは適切)、代わりに X-Host などの代替ヘッダーを使用して作成する場合を考えてみます (こちらは間違い)。このシナリオでは、攻撃者は自分のドメインを X-Host に挿入してリダイレクトを改ざんできます。ただし、そのリダイレクトをユーザーに送信する手段が必要です。

ここで、Web キャッシュポイズニングの出番です。Web キャッシュは通常、リクエストをオリジンに送信するのではなく、HTTP リクエストの一部を「キー」として使用して、キャッシュされたコンテンツを使用するタイミングを判断します。このキーには通常、Host ヘッダーが含まれ、そして他のヘッダーが含まれる場合もあります。こちらの例では、X-Host がキャッシュキーの一部ではないが、レスポンスで安全に使用されていない場合 (リダイレクトの例のように)、攻撃者はキャッシュを利用して他のユーザーに悪意のあるリダイレクトを配信することができます。攻撃者はその後、自分のリクエストをキャッシュに保存し、他のユーザーに提供する方法を見つけます。

Web キャッシュポイズニングの例を見てみましょう。まず攻撃者は、X-Host ヘッダーに悪意のあるドメインを含む次のリクエストをキャッシュします。このリクエストはリダイレクトに使用されます。

GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com

X-Host: www.attackers-domain.example.com

正常なユーザーがアプリケーションを訪問し、通常のリクエストを送信します。

GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.super-cool-fun-domain.example.com

攻撃者のリクエストがパスと Host ヘッダーに基づいてキャッシュされた場合、正常なユーザーは汚染されたキャッシュレスポンスを受け取り、攻撃者のページにリダイレクトされます。

HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php

Web キャッシュポイズニング攻撃は、キャッシュキーとして使用されるヘッダーと、アプリケーションがレスポンスを生成するために使用するヘッダーとの不一致に依存しています。上記の例では、X-Host ヘッダーがキャッシュされたレスポンスを改ざんし、ユーザーを実際のアプリケーションではなく悪意のあるサイトにリダイレクトする可能性がありました。

3. パスワードリセットポイズニング

パスワードリセットポイズニングは、前述のホストヘッダーポイズニングと非常に類似しています。脆弱なアプリケーションは、パスワードリセットワークフロー中にリクエストされたユーザーに送信するパスワードリセットリンクを作成するために、Host ヘッダーを使用します。たとえば、攻撃者が「alice」ユーザーのパスワードリセットを要求する以下の POST リクエストを送信したと仮定します。

POST /password-reset HTTP/1.1
Host: www.attackers-domain.example.com
...


user=alice

アプリケーションは、Host ヘッダーの値を使用してリセットリンクを作成し、そのリンクを含むメールを alice ユーザーに送信します。

www.attackers-domain.example.com?reset_token=super-random-reset-token-value-12345

ユーザーがリンクをクリックすると、攻撃者はリセットトークンを取得し、ユーザーのパスワードを自身の値にリセットすることができます。

4. サーバーサイド・リクエスト・フォージェリ

サーバー・サイド・リクエスト・フォージェリ (SSRF) は、攻撃者がサーバーサイドのアプリケーションに任意の場所へのリクエストを送信させることを可能にする脆弱性です。Host ヘッダー SSRF では、攻撃者はユーザーとサーバーサイドのアプリケーションの間にあるシステムのルーティングを悪用しています。このミドルウェア (例 : Load Balancer) が Host ヘッダー SSRF に対して脆弱である場合、攻撃者はこれを利用して、通常はアクセスできない内部システムとやり取りすることが可能です。これをテストする一般的な方法は、Host ヘッダーの値に一意でコントロールされたドメイン (例 : Portswigger の Burp Collaborator、もしくは ProjectDiscovery の interactsh) を指定することです。Host ヘッダー攻撃中に、その固有のドメインがターゲットアプリケーションのネットワークパス (例 : Load Balancer) 内のシステムから DNS ルックアップやその他のリクエストを受け取ると、SSRF の脆弱性にさらされる可能性があります。これらの攻撃は、実際には複雑な傾向にあるものの、James Kettle の研究で徹底的に示されているように、壊滅的な影響を及ぼすこともあります。

HTTP Host ヘッダー攻撃の実例

Host ヘッダー攻撃の種類を理解できたところで、実際の事例を見ていきましょう。

CVE-2022-29933 : Craft CMS におけるパスワードリセットポイズニング

SEC Consult の調査結果によると、Craft CMS のデフォルトのインストールでは、パスワード再設定メールを「X-Forwarded-Host」HTTP ヘッダーの値を使用して作成していることがわかりました。この例では、攻撃者は X-Forwarded-Host に自分のコントロールドメインを挿入し、alice ユーザーのパスワードリセットリンクを次のように改ざんします。

POST /index.php?p=admin/actions/users/send-password-reset-email HTTP/1.1
Host: <installation-domain>
X-Forwarded-Host: www.attackers-domain.example.com
...
Cookie: CRAFT_CSRF_TOKEN=[...]


loginName=alice@example.com

alice@example.com のユーザーがパスワードリセットメールを受信すると、そのメールには攻撃者がコントロールするドメインへのリンクが含まれています。

http://www.attackers-domain.example.com/index.php?p=admin/set-password&code=<reset-code>&id=<uuid>

ユーザーがリンクをクリックすると、攻撃者はリセットコードを取得し、パスワードをリセットしてアカウントを乗っ取ることができます。

Slack における X-Forwarded-Host インジェクションを介したブラインド SSRF

この攻撃は、弱い X-Forwarded-Host 検証を回避し、files.slack.com でのブラインド SSRF を実現します。まず、files.slack.com は処理中に Host ヘッダーおよび X-Forwarded-Host ヘッダーの有効性を検証し、files.slack.com でない場合は HTTP 500 レスポンスコードを返します。ただし、X-Forwarded-Host の検証は、ドメインの末尾に @ の文字を追加することで回避可能です。したがって、攻撃者はリクエストを取得するためのコールバックドメインを設定します (例 : Burp Collaborator、ProjectDiscoveryのinteractshを使用)。そして、次のリクエストを slack.files.com に送信します。

GET /<URI> HTTP/1.1
Host: files.slack.com
...
X-Forwarded-Host: files.slack.com@www.unique-attackers-domain.example.com

X-Forwarded-Host ヘッダーから作成された URL files.slack.com は、HTTP ユーザー (HTTP BasicAuth) として扱われ、www.unique-attackers-domain.example.com はホスト名として扱われます。攻撃者はバックエンドシステムからリクエストを受信し、SSRF が成功したことを確認します。ここから、いくつかの異なるブラインド SSRF テクニックを使用して、情報を漏洩させたり、バックエンドシステムと相互作用したりするなど、さまざまなことが可能になります。

HTTP Host ヘッダー攻撃を防ぐ方法

HTTP Host ヘッダー攻撃を防ぐ方法は複数存在しますが、それぞれの有効性と欠点は様々です。以下に、このタイプの攻撃を防ぐための実用的な解決策を紹介します。

アプリケーションコードで Host ヘッダーの値とそのバリエーションを使用しない

Host ヘッダー攻撃を防ぐ最も簡単な方法は、アプリケーションコードで Host ヘッダー値を使用しないことです。さらに、サーバー側の設定や相対 URL を使用することで、Host ヘッダー攻撃を完全に防御できます。

Host ヘッダーの値に対して厳格な検証を実施する

Host ヘッダー値を使用する必要がある場合、Host ヘッダー攻撃を防ぐために以下のテクニックを使用してください。

1. Host ヘッダーが許可された値のリストに含まれていることを確認します。たとえば、アプリケーションが3つのドメインのみを使用する場合は、Host ヘッダーがその3つの値のうち1つだけであることを確認します。

2. Host ヘッダーが1つだけ存在することを確認します。重複した Host ヘッダーは、検証とヘッダーの使用の際にリクエストから異なる値が取得される場合、検証を回避するために使用されることがあります。

3. Host ヘッダーの代替または上書きとしての X-Host や X-Forwarded-Host の使用は避けてください。やむを得ない場合は、Host ヘッダーに対して提供されているのと同じ推奨事項に従ってください。

Fastly が HTTP Host ヘッダー攻撃を防ぐ仕組み

Fastly のキャッシュポイズニング防止ガイドに従い、追加の保護対策が講じられていることを確認してください。

Fastly の次世代 Web アプリケーションファイアウォールをご利用の場合、HTTP Host ヘッダー攻撃に対する保護措置を追加して、無効な Host ヘッダー (例 : 許可されたドメインリストにないもの) を持つすべてのリクエストをブロックできます。

概要

Host ヘッダーはインターネット (および Fastly) の重要な要素ですが、Host ヘッダーが暗黙的に信頼されたり、追加機能に使用されていたり、不適切に設定されたりすると、攻撃者はこの動作を悪用して、異なる種類の悪意のあるコンテンツを挿入することが可能になります。これにより、Host ヘッダー攻撃、Web キャッシュ攻撃、パスワードリセット攻撃、サーバー・サイド・リクエスト・フォージェリ (SSRF) など、複数の種類の攻撃が可能になります。私たちが概説したソリューションと、キャッシュポイズニングを防ぐための Fastly のガイダンスを組み合わせることで、アプリケーションは Host ヘッダー攻撃のバリアントを防ぐことができます。