リバースプロキシを使用したホストヘッダー攻撃
そのため、AcunetixWebセキュリティスキャンによって特定された問題の調査を任されました。
スキャンの詳細は次のとおりです。
Host_header_attack
ホストヘッダー攻撃の自動検出
十分な評判がないため、まだ2つ以上のリンクを投稿することはできませんが、上記のリンクの最初のスケルトンスクライブのリファレンスでは、エクスプロイトについて詳しく説明しており、この件に関する主な情報源のようです。
推奨される回避策は、Hostヘッダーを使用する代わりに、SERVER_NAMEを使用する「ダミー」のデフォルトの仮想ホストおよびアプリケーションの使用を提案します。これらの提案は、真のOriginサーバーについて話す場合には最適ですが、リバースプロキシを使用している場合はそれほど重要ではありません。
Acunetixによってスキャンされている当社のWebサイトは、リバースプロキシの背後にあるアプリケーションサーバーとして設定されています。この場合、リバースプロキシはiPlanetですが、Apache2.4.7でmod_proxyを使用して同じ動作を確認しました。これがどのように機能するか、そしてなぜそれがAcunetixスキャンをトリガーするのかです。
絶対URIを使用して要求が行われると（スキャナーと同様）、RFC仕様によれば、サーバーはHostヘッダーを無視し、代わりに絶対URI内にあるホストを使用することを目的としています。これは私たちが見ている動作であり、その結果、Hostヘッダーの値が正しくない/悪意のある場合でも、正しい仮想ホストが選択されます。ここまでは順調ですね。
この問題は、リバースプロキシがこの要求をバックエンドのOriginサーバーに渡すときに発生します。これを行うと、元のホストヘッダーがリクエストとともに渡されます。 Hostヘッダーの値が正しくないか悪意がある場合、これはOriginサーバーに返されます。 Originサーバーが仮想ホストを実装していない場合、Hostヘッダーが正しいことを確認する必要はありません。
この結果、Hostヘッダーの値を使用しようとするOrigin Web/appサーバーで実行されているアプリケーションは、悪意のあるホストを使用することになります。値。 SERVER_NAMEを使用しても、サイトのサーバー名（または真のホスト）はリバースプロキシによって転送されず、オリジンサーバーは引き続きホストヘッダー値で応答するため、このインスタンスでは役に立ちません。ここでUseCanonicalNameとServerNameディレクティブを使用することも役に立ちません。これは、元のリクエストのサーバー名が必要であり、複数の値になる可能性があるためです。
この「攻撃」は2013年に特定されましたが、上記の参照から詳細を繰り返すだけでなく、それに関する多くの情報を見つけることができません。 HTTPクライアントは、転送プロキシサーバーと通信していない限り、絶対URIを送信しないため、これは一般的な問題ではありません。これは、すべてのregularリクエストが相対URIであり、この問題が解消されることを意味します（悪意のあるホストヘッダーは、リバースプロキシの「ダミー」またはデフォルトの仮想ホストでスタックします）。
リクエストがバックエンドに送信される前に、リバースプロキシがホストヘッダーをSERVER_NAMEにアクティブに設定する回避策を作成しました。これは機能しますが、それが賭けの慣行/基準に反する解決策である可能性があるかどうか心配しています。このようにHostヘッダーを設定すると、何かが壊れますか？これについてブレインストーミングを行いましたが、そうなるシナリオは考えられません。明日、Oracleに電話をかけて、フィードバックをもらいます。
私が試した2つのWebサーバー製品の見落としであるという、これは非常にフリンジなケースであるように思われますが、対処しないと何かが長く続くとは想像できません。私は何かが足りないに違いない。
申し訳ありませんが、とても長いですが、何かアイデアはありますか？ :)このエッセイの「質問」の部分はこれになります：
- 上記の私の回避策は良い解決策になるでしょうか、それとも物事を壊すでしょうか？
- この問題の既知の解決策はありますか？
リバースプロキシは、デフォルトでHost：ヘッダーを修正することになっています。そうしないことはバグであり、開発者に報告する必要があります。
から RFC 7230セクション5.4 ：
プロキシが絶対形式のrequest-targetでリクエストを受信すると、プロキシは受信したHostヘッダーフィールド（存在する場合）を無視し、代わりにrequest-targetのホスト情報に置き換えなければなりません。このようなリクエストを転送するプロキシは、受信したホストフィールド値を転送するのではなく、受信したリクエストターゲットに基づいて新しいホストフィールド値を生成する必要があります。
このRFCの以前のバージョンであるRFC2616は、それほど具体的ではなかったことに注意してください。 それは言っただけです ：
HTTP/1.1プロキシは、転送する要求メッセージに、プロキシによって要求されているサービスを識別する適切なホストヘッダーフィールドが含まれていることを確認する必要があります。
プロキシの動作は、古い仕様または新しい仕様のいずれかに準拠しているとは言えません。
それまでの間、正しい動作が導入されるため、回避策は問題ありません。
同じ問題を修正する必要があります。Acunetixはこの脆弱性を報告しました。リバースプロキシはありませんが、同じ解決策を考え出しました。vHostでHostヘッダーを明示的に設定したので、常に必要なものになります。ただし、スキャンを再度実行すると、問題がまだ残っていることがわかります。
PostmanとcURLを使用してソリューションを検証し、悪意のあるHostまたはX-Forwarded-Hostヘッダーがエコーされなくなったことに気付きましたが、Acunetixはまだ脆弱性を示しています...
私は2つのソリューションを実装しました：
1）キャッチオールvHostを作成しました... 2）サーバーvHostにHostヘッダーを明示的に設定します
ポイント1は、Apacheがリクエストを名ベースのvHostに渡さないように、単にHostヘッダーを変更しないように保護することであり、ポイント2はX-Forwarded-Hostの変更を並べ替えます。
他には何があるの？
Apache 2.4 Ubuntu 14.04.5