hop-by-hop headers
これは投稿の要約です https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers
Hop-by-hopヘッダーは、単一のトランスポートレベル接続に特有で、主にHTTP/1.1で2つのノード（クライアント-プロキシやプロキシ-プロキシ）間のデータを管理するために使用され、転送されることを意図していません。標準のhop-by-hopヘッダーには、Keep-Alive、Transfer-Encoding、TE、Connection、Trailer、Upgrade、Proxy-Authorization、およびProxy-Authenticateが含まれ、RFC 2616で定義されています。追加のヘッダーは、Connectionヘッダーを介してhop-by-hopとして指定できます。
Hop-by-Hopヘッダーの悪用
プロキシによるhop-by-hopヘッダーの不適切な管理は、セキュリティ上の問題を引き起こす可能性があります。プロキシはこれらのヘッダーを削除することが期待されていますが、すべてのプロキシがそうするわけではなく、潜在的な脆弱性を生み出します。
Hop-by-Hopヘッダー処理のテスト
特定のヘッダーがhop-by-hopとしてマークされているときのサーバーの応答の変化を観察することで、hop-by-hopヘッダーの処理をテストできます。ツールやスクリプトを使用してこのプロセスを自動化し、プロキシがこれらのヘッダーをどのように管理しているかを特定し、誤設定やプロキシの動作を明らかにすることができます。
Hop-by-hopヘッダーの悪用は、さまざまなセキュリティ上の影響を引き起こす可能性があります。以下は、これらのヘッダーが潜在的な攻撃のためにどのように操作されるかを示すいくつかの例です。
X-Forwarded-Forを使用したセキュリティ制御の回避
X-Forwarded-Forを使用したセキュリティ制御の回避攻撃者は、X-Forwarded-Forヘッダーを操作してIPベースのアクセス制御を回避できます。このヘッダーは、プロキシがクライアントの発信IPアドレスを追跡するために使用されることがよくあります。しかし、プロキシがこのヘッダーをhop-by-hopとして扱い、適切な検証なしに転送する場合、攻撃者は自分のIPアドレスを偽装できます。
攻撃シナリオ:
攻撃者は、プロキシの背後にあるWebアプリケーションにHTTPリクエストを送信し、
X-Forwarded-Forヘッダーに偽のIPアドレスを含めます。攻撃者は、
Connection: close, X-Forwarded-Forヘッダーも含め、プロキシにX-Forwarded-Forをhop-by-hopとして扱うよう促します。誤設定されたプロキシは、偽装された
X-Forwarded-ForヘッダーなしでリクエストをWebアプリケーションに転送します。Webアプリケーションは、元の
X-Forwarded-Forヘッダーを見ていないため、リクエストが信頼されたプロキシから直接来たものと見なす可能性があり、無許可のアクセスを許可する可能性があります。
Hop-by-Hopヘッダー注入によるキャッシュポイズニング
キャッシュサーバーがhop-by-hopヘッダーに基づいてコンテンツを誤ってキャッシュする場合、攻撃者は悪意のあるヘッダーを注入してキャッシュを汚染する可能性があります。これにより、同じリソースを要求するユーザーに不正確または悪意のあるコンテンツが提供されます。
攻撃シナリオ:
攻撃者は、キャッシュされるべきでないhop-by-hopヘッダー（例：
Connection: close, Cookie）を含むリクエストをWebアプリケーションに送信します。不適切に構成されたキャッシュサーバーは、hop-by-hopヘッダーを削除せず、攻撃者のセッションに特化した応答をキャッシュします。
同じリソースを要求する将来のユーザーは、攻撃者向けに調整されたキャッシュされた応答を受け取り、セッションハイジャックや機密情報の露出につながる可能性があります。
Last updated
