HTTPoxyの脆弱性からサーバーを保護する方法

HTTPoxyとは何ですか？

2016年7月18日に、https：//httpoxy.org/ [HTTPoxy]と呼ばれるCGIアプリケーションの脆弱性が公開されました。攻撃者は、リクエストにHTTP `+ Proxy +`ヘッダーを渡すことで脆弱な展開を悪用できます。これにより、バッキングサービスにアクセスするときにアプリケーションが使用するURLが変更されます。これは、資格情報の漏洩、アプリケーションへの応答の変更などに使用できます。

この脆弱性は、バックエンドプロキシサービスの場所を指定するために頻繁に使用される環境変数 `+ HTTP_PROXY `と、HTTPクライアントヘッダー ` Proxy `の名前の衝突によって引き起こされます。 https://tools.ietf.org/html/rfc3875#section-4.1.18[CGI specification]は、ネームスペース用に ` HTTP_ `プレフィックスを付けて環境に渡されるクライアント提供のヘッダーを呼び出します。このマングリングは、 ` HTTP_PROXY `のような設定変数と衝突します。これも ` HTTP_ +`で始まります。 CGIアプリケーションまたはライブラリが追加の処理なしでこの変数を使用する場合、プロキシサービスへの接続を試行するときにクライアントによって提供された値を使用することになります。

この脆弱性はさまざまなCGIのような実装に影響を与えるため、多くのセキュリティ脆弱性識別子が作成されています。http：//www.cve.mitre.org/cgi-bin/cvename.cgi？name = 2016-5385 [CVE- 2016-5386]、http：//www.cve.mitre.org/cgi-bin/cvename.cgi？name = CVE-2016-5386 [CVE-2016-5386]、http：//www.cve.mitre。 org / cgi-bin / cvename.cgi？name = CVE-2016-5387 [CVE-2016-5387]、http：//www.cve.mitre.org/cgi-bin/cvename.cgi？name = CVE-2016 -5388 [CVE-2016-5388]、http：//www.cve.mitre.org/cgi-bin/cvename.cgi？name = CVE-2016-1000109 [CVE-2016-1000109]、およびhttp：// www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000110[CVE-2016-1000110]（この記事の執筆時点では、これらは予約されていますが、記入されていません）。

HTTPoxyの脆弱性は2001年以来いくつかの形式で知られていますが、最近まで広範囲の問題として認識されていませんでした。多くの展開に影響する可能性がありますが、軽減策は非常に単純で単純です。

脆弱なサーバーとアプリケーション

HTTPoxyは、多くのCGI実装に見られる一般的な脆弱性です。アプリケーションまたはサーバーはCGI仕様を正しく実装できますが、依然として脆弱です。

展開が脆弱になるには、次のことを行う必要があります。

* `+ HTTP_PROXY +`環境変数を使用してプロキシ接続を設定します*：アプリケーションコード自体または使用されるライブラリで利用します。これは、環境を使用してプロキシサーバーを構成するかなり標準的な方法です。
* HTTPを使用したバックエンドサービスへのリクエストの作成*：名前の衝突は `+ HTTP_ +`プレフィックスに固有であるため、HTTPを使用したアプリケーションによって行われたリクエストのみが影響を受けます。 HTTPSまたはその他のプロトコルを使用したリクエストは脆弱ではありません。
* CGIまたはCGIのような環境で動作します*：クライアントヘッダーが `+ HTTP_ +`プレフィックス付き環境変数に変換されるデプロイメントは脆弱です。これに対応するのは、CGIまたはFastCGIなどの関連プロトコルの準拠実装です。

ご覧のとおり、デプロイメントが脆弱になるには、デプロイメント固有の要素とアプリケーション固有の要素の組み合わせが必要です。展開が影響を受けるかどうかをテストするために、https：//rehmann.co/ [Luke Rehmann]は単純なhttps://httpoxy.rehmann.co/ [公開されているサイトの脆弱性をチェックするサイト]を作成しました。

言語固有の情報

CGIのような展開は、他の言語よりもPHPエコシステムではるかに一般的であるため、特にPHPアプリケーションを監査する必要があります。さらに、一般的なライブラリで `+ getenv +`メソッドが広く使用されているため、この問題は増幅されます。これは、構成変数だけでなく、サニタイズされていないユーザー入力を返すことはすぐにはわかりません。現在影響を受けている特定のライブラリは、Guzzle（バージョン4.0.0rc2以降）、Artax、およびComposerのStreamContextBuilderクラスです。

CGIを使用して展開した場合に脆弱であることが判明した他の言語は、PythonとGoです。これらの言語は、他の脆弱性のない方法を使用してより一般的に展開されます。ただし、CGIが使用される場合、動作を変更せずに `+ HTTP_PROXY +`変数を単純に読み取るライブラリは脆弱です。

脆弱性を克服する方法

幸いなことに、HTTPoxyは比較的簡単に修正できます。この脆弱性は、Webサーバー層またはアプリケーションまたはライブラリから対処できます。

アプリケーションまたはライブラリは、CGI環境にある場合、 `+ HTTP_PROXY +`変数を無視できます。
アプリケーションまたはライブラリは、異なる環境変数を使用してプロキシ接続を構成できます
Webサーバーまたはプロキシは、クライアントリクエストで受信した `+ Proxy +`ヘッダーを設定解除できます

脆弱なライブラリを使用している場合、問題に対処するためのパッチが利用可能になるまで、サーバー側の脅威を軽減する必要があります。ライブラリまたはアプリケーションの作成者で、プロジェクトがプロキシバックエンドを設定するために `+ HTTP_PROXY `変数に依存している場合、CGIのような環境で実行しているときに衝突しない代替変数の使用を検討してください。 Rubyおよび他のいくつかのプロジェクトは、この目的のために ` CGI_HTTP_PROXY +`を使用します。

`+ Proxy `ヘッダーは標準のHTTPヘッダーではないため、ほとんどすべての場合で無視しても問題ありません。これは、アプリケーション自体にリクエストを送信するために使用されるWebサーバーまたはロードバランサーで実行できます。 HTTPヘッダー ` Proxy +`には標準的な正当な目的がないため、ほとんどの場合ドロップできます。

一般的なWebサーバー、ロードバランサー、またはプロキシは、適切なヘッダーを設定解除できます。

Apacheを使用したHTTPプロキシヘッダーの削除

Apache HTTP Webサーバーを実行している場合、 `+ mod_headers +`モジュールを使用してすべてのリクエストのヘッダーを設定解除できます。

UbuntuおよびDebianサーバー

UbuntuまたはDebianサーバーで `+ mod_headers +`を有効にするには、次のように入力します。

sudo a2enmod headers

その後、グローバル構成ファイルを開きます。

sudo nano /etc/apache2/apache2.conf

下に向かって、以下を追加します。

/etc/apache2/apache2.conf

. . .
RequestHeader unset Proxy early

ファイルを保存して閉じます。

構文エラーの構成を確認します。

sudo apache2ctl configtest

構文エラーが報告されない場合、サービスを再起動します。

sudo service apache2 restart

CentOSおよびFedoraサーバー

従来のインストールでは、デフォルトで `+ mod_headers `モジュールを有効にする必要があります。 ` Proxy +`ヘッダーの設定を解除するには、グローバル設定ファイルを開きます：

sudo nano /etc/httpd/conf/httpd.conf

下に向かって、以下を追加します。

/etc/httpd/conf/httpd.conf

. . .
RequestHeader unset Proxy early

完了したら、ファイルを保存して閉じます。

次のように入力して、構文エラーを確認します。

sudo apachectl configtest

構文エラーが報告されていない場合は、次を入力してサービスを再起動します。

sudo service httpd restart

Nginxを使用したHTTPプロキシヘッダーの削除

Nginxでは、緩和も同様に簡単です。サーバーまたはアップストリームで実行されているCGIのような環境の環境を簡単にサニタイズできます。

UbuntuおよびDebianサーバー

UbuntuおよびDebianサーバーでは、FastCGIプロキシを設定するときに、通常、FastCGIパラメーターは `+ fastcgi_params `または ` fastcgi.conf `ファイルのいずれかから含まれます。これらのファイルの両方で ` HTTP_PROXY +`ヘッダーを設定解除できます：

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

FastCGIプロキシを構成するときにファイルの1つを調達していない場合は、プロキシロケーション自体にこの同じ行を含めるようにしてください。

/etc/nginx/sites-enabled/some_site.conf

. . .
   location ~ \.php$ {
       . . .

       . . .
   }
}

従来のHTTPプロキシにNginxを使用している場合、HTTP `+ Proxy `ヘッダーもクリアする必要があります。 HTTPプロキシヘッダーは、 ` / etc / nginx / proxy_params `ファイルで設定されます。次のように入力して、そのファイルに「 Proxy +」ヘッダーを設定解除するルールを追加できます。

echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params

繰り返しますが、サーバーブロック構成内からこのファイルを取得していない場合は、プロキシロケーション自体に追加する必要があります。

/etc/nginx/sites-enabled/some_site.conf

. . .
   location /application/ {
       . . .
       proxy_pass http://127.0.0.1;

       . . .
   }
}

次のように入力して、構文エラーを確認します。

sudo nginx -t

エラーが報告されない場合は、サービスを再起動します。

sudo service nginx restart

CentOSおよびFedoraサーバー

CentOSおよびFedoraのNginxは、同じ `+ fastcgi_params `および ` fastcgi.conf `ファイルを使用してFastCGIプロキシを構成します。次のように入力して、これらのファイルの両方で ` HTTP_PROXY +`ヘッダーを設定解除します。

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

FastCGIプロキシを構成するときにこれらのファイルのいずれかを調達していない場合は、プロキシロケーション自体にこの同じ行を含めるようにしてください。

/etc/nginx/nginx.conf

. . .
   location ~ \.php$ {
       . . .

       . . .
   }
}

従来のHTTPプロキシにNginxを使用している場合、HTTP + Proxy +`ヘッダーもクリアする必要があります。 `+ proxy_pass`を実行している任意の場所で + Proxy`ヘッダーの設定を解除するルールを追加する必要があります。 `+ proxy_pass +`がどこで使用されているかわからない場合は、設定ディレクトリを簡単に検索できます。

grep -r "proxy_pass" /etc/nginx

Output/etc/nginx/nginx.conf.default:        #    proxy_pass   http://127.0.0.1;

コメントアウトされていない結果（上記の例のように）は、 `+ proxy_set_header Proxy" "; +`を含めるように編集する必要があります。

/etc/nginx/nginx.conf

. . .
   location /application/ {
       . . .
       proxy_pass http://127.0.0.1;

       . . .
   }
}

次のように入力して、構文エラーを確認します。

sudo nginx -t

エラーが報告されない場合は、サービスを再起動します。

sudo service nginx restart

HAProxyを使用したHTTPプロキシヘッダーの削除

HAProxyを使用してトラフィックをアプリケーションサーバーに転送する場合、トラフィックを転送する前に `+ Proxy +`ヘッダーを削除できます。

編集のために `+ / etc / haproxy / haproxy.cfg +`ファイルを開きます：

sudo nano /etc/haproxy/haproxy.cfg

設定の + frontend +、 + backend +、または `+ listen `セクションで ` http-request +`ディレクティブを設定できます。

/etc/haproxy/haproxy.cfg

frontend www

   . . .

backend web-backend

   . . .

listen appname 0.0.0.0:80

   . . .

これらは各セクションで設定する必要はありませんが、それらを含めることは問題ありません。完了したら、ファイルを保存して閉じます。

次のように入力して構文を確認します。

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

問題が見つからない場合は、次を入力してサービスを再起動します。

sudo service haproxy restart

結論

HTTPoxyの脆弱性はかなり前から公開されており、Webにデプロイされた多数のアプリケーションに影響を及ぼす可能性があります。幸いなことに、Webサーバーに固有のヘッダー変更機能を使用して簡単に修正できます。

TOC

HTTPoxyの脆弱性からサーバーを保護する方法

HTTPoxyとは何ですか？

脆弱なサーバーとアプリケーション

言語固有の情報

脆弱性を克服する方法

Apacheを使用したHTTPプロキシヘッダーの削除

UbuntuおよびDebianサーバー

CentOSおよびFedoraサーバー

Nginxを使用したHTTPプロキシヘッダーの削除

UbuntuおよびDebianサーバー

CentOSおよびFedoraサーバー

HAProxyを使用したHTTPプロキシヘッダーの削除

結論

Related