PHP、Python、およびその他の Web サイトアプリケーションがリモートプロキシの脆弱性を公開します: httpoxy

[深セン] 源創輝: 午後 5 時 26 分、パーティー会場があなたを待っています。」

これは、PHP、Go、Python などの言語の CGI アプリケーションを対象とした脆弱性です。

httpoxy は、CGI または CGI に似た方法で実行されるアプリケーションに影響を与える脆弱性ファミリーの名前です。簡単に言うと、名前空間の競合の問題です。

RFC 3875 (CGI) は、 HTTP リクエストのProxyヘッダーから環境変数を直接設定するHTTP_PROXY方法を定義しています。
HTTP_PROXY送信エージェントを構成するために一般的に使用される環境変数です。

この欠陥により、リモート攻撃が可能になります。PHP または CGI プログラムを実行している場合は、すぐに Proxy ヘッダーをブロックする必要があります。すぐに！具体的な手順については、以下を参照してください。 httpoxy はサーバー側の Web アプリケーションの脆弱性です。このコードをサーバー側に展開しない場合は、心配する必要はありません。

Web アプリケーションにこの脆弱性がある場合はどうなりますか?

この脆弱性を悪用する HTTP クライアントがリクエストを行うと、次のことが可能になります。

Web アプリケーションを介して他の URL にリクエストをプロキシする
指定されたリモートアドレスとポートを開くようにサーバーに直接要求します。
サーバーリソースを浪費し、攻撃者が指定されたリソースにアクセスする

httpoxy の脆弱性は非常に簡単に悪用されます。セキュリティ担当者ができるだけ早くこの脆弱性をスキャンし、迅速に修正してくれることを願っています。

どちらが影響を受けますか?

次の状況では、セキュリティの脆弱性が存在する可能性があります。

コードは CGI コンテキストで実行され、HTTP_PROXY実際の環境変数またはシミュレートされた環境変数になります。
HTTP_PROXYプロキシ機能をサポートする信頼できるHTTP クライアント
クライアントはリクエスト内で HTTP (または HTTPS) リクエストを開始します。

この欠陥が見つかった環境は次のとおりです。

言語	環境	HTTPクライアント
PHP	php-fpm mod_php	ガズル 4+
パイソン	wsgiref.handlers.CGIHandlerTwisted.web.twcgi.CGIScript	リクエスト
行く	ネット/http/cgi	ネット/http

確かに、欠陥が特定されていない言語や環境はたくさんあります。

PHP

この欠陥が存在するかどうかはアプリケーションコードと PHP ライブラリによって異なりますが、影響は非常に広範囲に及ぶようです。
この欠陥のあるライブラリがユーザー要求の処理プロセスで使用されている限り、悪用される可能性があります。
この欠陥のあるライブラリを使用すると、その欠陥はすべての PHP バージョンに影響します。
- FastCGI モードでデプロイされた HHVM などの代替 PHP ランタイム環境にも影響を与える可能性があります。
Guzzle や Artax などのライブラリが影響を受けることが確認されており、さらに多くのライブラリが影響を受ける可能性があります。
- Guzzle 4.0.0rc2 以降のバージョンは影響を受けますが、Guzzle 3 以前のバージョンは影響を受けません
- 他の例には、Composer の StreamContextBuilder ユーティリティクラスが含まれます。

たとえば、Drupal の Guzzle 6 モジュールを使用してアウトバウンドリクエスト (天気予報 API のリクエストなど) を開始する場合、モジュールによって開始されるリクエストには httpoxy の欠陥が存在します。

パイソン

Python コードが欠陥となるのは、CGI モードでデプロイされた場合のみです。一般的に、欠陥のあるコードは次のようなwsgiref.handlers.CGIHandlerCGI コントローラを使用します。
- 通常の方法でデプロイされた Python Web アプリケーションは影響を受けません (ほとんどの人は WSGI または FastCGI を使用しており、これら 2 つは影響を受けません)。そのため、影響を受ける Python アプリケーションは PHP よりもはるかに少なくなります。
- os.environ は CGI データによって汚染されていないため、wsgi は影響を受けません。
欠陥のあるリクエストライブラリは信頼して使用する必要がありos.environ['HTTP_PROXY']、コンテンツチェックは行われません。

行く

影響を受けるには、Go コードを CGI の下にデプロイする必要があります。一般的に影響を受けるコードはnet/http/cgiパッケージを使用します
- Python と同様、これは Go を Web アプリケーションとしてデプロイする通常の方法ではありません。影響を受けるケースは非常に少ないので、
- 比較すると、Go のnet/http/fcgiパッケージは実際の環境変数を設定しないため、影響を受けません。
欠陥のあるバージョンは信頼され、内容をチェックせずにnet/http送信リクエストで使用される必要があります。HTTP_PROXY

今、直してください

最善の解決策は、リクエストヘッダーがアプリケーションを攻撃する前に、早い段階でProxyリクエストヘッダーをブロックすることです。簡単で安全です。

Proxyリクエストヘッダーは IETF によって定義されておらず、IANA のメッセージヘッダーレジストリにもリストされていないため、安全であると言われています。これは、このヘッダーの使用が非標準であり、アドホックに使用されていないことを示します。
標準に準拠した HTTP クライアントとサーバーは、このヘッダーを決して読み取ったり、送信したりしないでください。
このヘッダーをリクエストから削除することも、それを使用するリクエストを完全にブロックすることもできます。
アップストリームがパッチをリリースしない場合は、自分で修正できます
- HTTP リクエストを受信時にチェックすると、欠陥のある多くのアプリケーションを一度に修正できる
- リバースプロキシとアプリケーションファイアウォールの背後でアプリケーションをカリングするProxyリクエストヘッダーは安全である

リクエストヘッダーをブロックする方法はProxy構成によって異なります。最も簡単な方法は、Web アプリケーションファイアウォールでこのヘッダーをブロックするか、Apache や Nginx で直接ブロックすることです。これを行う方法については、次のようなヒントがあります。

Nginx/高速CGI

PHP-FPM および PHP-PM に渡されるリクエストヘッダーをブロックするには、次のステートメントを使用します。このステートメントは、(使用する構成ファイルに応じて) fastcgi.conf または fastcgi_param に配置できます。

fastcgi_param HTTP_PROXY "";

PHP は FastCGI モードに欠陥があります (ただし、Nginx FastCGI を使用する他のほとんどの言語は影響を受けません)。

アパッチ

Apache および Tomcat などの他の Apache ソフトウェアプロジェクトに対する具体的な影響範囲については、Apache Software Foundation の公式発表を参照することをお勧めします。以下にいくつかの重要なメッセージを示します。

Apache HTTP サーバーを使用してmod_cgiGo または Python で書かれたスクリプトを実行する場合、それらは影響を受けます (HTTP_PROXY環境変数が "real" である場合)。mod_phpPHP スクリプトで使用されるため、この欠陥も存在します。

mod_headersモジュールを使用する場合は、Proxy次の構成でリクエストをさらに処理する前にリクエストヘッダーの設定を解除できます。

RequestHeader unset Proxy early

mod_securityモジュールを使用する場合、ルールを使用してリクエストヘッダーを持つリクエストSecRuleを拒否できます。Proxy以下は例です。SecRuleEngineオンになっていることを確認してください。自分の状況に応じて調整できます。

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

最後に、Apache Traffic Server を使用している場合、それ自体は影響を受けません。ただし、これを使用してプロキシリクエストヘッダーを削除し、その背後にある他のサービスを保護することができます。詳細については、 ASF ガイダンスを参照してください。

HAプロキシ

次の構成を通じてリクエストヘッダーを削除します。

http-request del-header Proxy

ワニス

このヘッダーをキャンセルするには、既存の vcl_recv セクションにヘッダーを追加してください。

sub vcl_recv {
    [...]
    unset req.http.proxy;
    [...]
}

OpenBSD 中継

このヘッダーを削除するには、次のステートメントを使用します。それを既存のフィルター内に置きます。

http protocol httpfilter {
    match request header remove "Proxy"
}

lighttpd（<= 1.4.40）

Proxyヘッダーを含むリクエストをバウンスします。

次の内容のファイルを作成し/path/to/deny-proxy.lua、lighttpd に対して読み取り専用にします。

if (lighty.request["Proxy"] == nil) then return 0 else return 403 end

モジュールlighttpd.confをロードして上記の lua コードを実行するように変更します。mod_magnet

server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/path/to/deny-proxy.lua" )

lighttpd2（開発中）

リクエストからProxyヘッダーを取り除きます。次のステートメントを追加しますlighttpd.conf。

req_header.remove "Proxy";

クライアント側の PHP 修正は効果がありません

この欠陥を解決するためのユーザー側の修正はありませんので、気にする必要はありません。

を使用しても返される値にunset($_SERVER['HTTP_PROXY'])は影響しないため、役に立ちませんgetenv()
使用してもputenv('HTTP_PROXY=')効果はありません (putenv は実際の環境変数の値にのみ影響し、リクエストヘッダーの値には影響しません)

httpoxy の歴史

この脆弱性は 15 年前に初めて発見されました。

2001 年 3 月に、Randal L. Schwartz が libwww-perl のこの欠陥を発見し、修正しました。

2001 年 4 月、Cris Bailiff はカールのこの欠陥を発見し、修正しました。

この欠陥は、 2012 年 7 月に Ruby チームのタナカアキラ氏によって実装中に発見されましたNet::HTTP。HTTP_PROXY

この欠陥は、2013 年 11 月に nginx メーリングリストで言及されました。発見者のジョナサン・マシューズは確信が持てませんでしたが、結局彼は正しかったことが分かりました。

Stefan Fritsch は、2015 年 2 月に Apache httpd-dev メーリングリストでこれについて言及しました。

この欠陥は 2016 年 7 月に Vend セキュリティチームの Scott Geary によって発見され、多くの最新のプログラミング言語や PHP などのライブラリに影響を与えます。

したがって、この欠陥は長年にわたって眠っており、多くの人がさまざまな側面でその存在を発見しましたが、他の言語やライブラリへの影響については考慮されていませんでした。セキュリティ研究者は、この目的のために特別に Web サイト(https://httpoxy.org/)を開設しています。ここで詳細を確認できます。