[〜#〜] httpoxy [〜#〜] と呼ばれる、ファンシーな名前のブランド化された新しい脆弱性があります。
ここで私の質問:TLS経由で提供されるサイトも影響を受けますか?または、これはHTTPサイト(暗号化されていない通信チャネル)のみの問題ですか?
あなたが投稿したリンクを読むまで、私はこれについて知りませんでしたので、この回答を信頼できるものとして見ないでください。影響を受けていないことが完全に確認されるまで、 "Immediate Mitigation" に記載されている予防策を講じることをお勧めします。
まず、この脆弱性はどのように機能しますか?これは、PHP "How it works" で説明されている例の短縮形です:
Proxy
ヘッダーが設定されたリクエストを、攻撃者が制御する悪意のあるIPに送信します。getenv("HTTP_NAME_OF_HEADER")
、またはこの場合はgetenv("HTTP_PROXY")
になります。getenv("HTTP_PROXY")
を読み取ることもできますが、ヘッダーを取得するのではなく、プロキシを使用する必要があるかどうかを確認します発信トラフィック用。攻撃者が送信したIPは、プロキシとして使用されます。ここで重要なのは、ここでは2つの要求が行われていることです。
AにHTTPSを使用する場合は問題ありません(これが「TLSを介して提供されるサイト」が意味することだと思います)。それはとにかくプレーンな古いHTTPに暗号化されます。だからあなたは脆弱です。
ただし、BにHTTPSを使用する場合は問題になる可能性があります。( hectorct がコメントで指摘されているため)攻撃者はクライアントが証明書をチェックし、TLSが良いなど。彼らがこれらの一節で話しているのはその2番目の要求です(私のハイライト):
脆弱であるためにはいくつかのことが必要です:
- CGIのようなコンテキストで実行されるコード。ここで、
HTTP_PROXY
は実際のまたはエミュレートされた環境変数になります。- HTTP_PROXYを信頼し、それをプロキシとして構成するHTTPクライアント
- 要求ハンドラー内で使用され、HTTP(HTTPSではなく)要求を行うそのクライアント
そしてもちろん、機能するもう1つの多層防御戦略は、外部の世界へのサイトの接続を保護するためだけでなく、内部要求にHTTPSを使用することです。これらは
HTTP_PROXY
の影響を受けません。
TLSはエンドツーエンドの暗号化です。つまり、クライアントとサーバー間のトラフィックは暗号化されており、たとえばMitM攻撃を実行しているユーザーはアクセスできません。これは、サーバーを保護するものではなく、送信されるデータのみを保護します。つまりyesそれはhttpからもhttpsからも利用できます。