アカウント名:
パスワード:
HTTPリクエストヘッダーとして送られてきた Proxy が環境変数 HTTP_PROXY にセットされるのが問題なだけなので、リクエストヘッダーの Proxy を落とすだけで対策可能です。
PHPに関するHTTPOXY脆弱性の問題と対応方法 [ichikaway.com] によると、Apache (mod_header が使用可能な場合) なら、
RequestHeader unset Proxy
とするだけで対策可能です。RequestHeader ディレクティブ [apache.org] は大文字と小文字は区別しないので、proxy とか proXY が送られてきても大丈夫です。
そのほか、HTTP ではなく HTTPS を使うのも対策になります（不正なプロキシを経由して通信内容が書き換わると証明書のエラーとなるため）。cgi がインターネットを経由して HTTP 通信（平文）で情報を
> そのほか、HTTP ではなく HTTPS を使うのも対策になります（不正なプロキシを経由して通信内容が書き換わると証明書のエラーとなるため）
これ、CGI実行プロセスからさらに外部アクセスするときのproxy設定が乗っ取られるわけだから、サーバ自身のHTTPS設定とは関係ないですよね。
確かに、さらに外部アクセスする先のサーバ（攻撃を受けたのとは別のサーバ）がHTTPS化され、証明書の検証を省いていなければエラーになりますが、そちらは外部サーバなわけだから自分ではコントロールできないし、オレオレ証明書で証明書検証を外していたり（内部ネットワーク内でアクセスしている場合）することもままあるわけで、
「HTTP ではなく HTTPS を使うのも対策になります」
と言い方は混乱を招くのでは？「（攻撃を受ける）サーバでHTTPSを使うのは対策にはならない」のでは？
「（攻撃を受ける）サーバでHTTPSを使うのは対策にはならない」のでは？
その通りです。
外部サーバを自分で管理していない場合であっても、外部サーバに HTTPS で接続すれば（証明書の検証を行う設定ならば）、不正なプロキシによるデータ改ざんは防げます（正確には改ざんを検知してエラーを発生させることができます。エラーが発生することにより正常なサービスが提供できなくなる問題は残ります）。そのため、今まで cgi から外部APIに HTTP で接続するようにしていた場合、HTTPS 接続に変更するといった対策は有効です。
勿論、接続先のAPI等が HTTP (平文) 接続にしか対応しておらず、HTTPSでの接続を受け付けない場合にはどうしようもないですが、一般公開されているAPIの場合、TLS非対応のAPIは少なくなってきています。
API 等を HTTPS に対応させることは、自分が管理しているサーバじゃないとできないので、「cgi から接続する先のサーバを自分で管理している場合には Let's Encrypt [letsencrypt.jp] や その他の無料SSL/TLS証明書 [jstream.jp] でも構わないので HTTPS にすると良いでしょう」と「自分で管理している場合」に限定する文言を入れました。
「HTTP ではなく HTTPS を使うのも対策になります」と言い方は混乱を招くのでは？
と言い方は混乱を招くのでは？
「HTTPリクエストヘッダーとして送られてきた Proxy が環境変数 HTTP_PROXY にセットされることを防ぐ」、あるいは「環境変数 HTTP_PROXY を無視する」ことが httpoxy 問題への根本的な対策ではあるのですが、インターネット経由で外部APIと通信する CGI (php を含むWebアプリケーション) が多くなっており、CGIがインターネット経由で外部APIから HTTP (平文) で情報を取得すること自体に別の危険性（通信の傍受・改ざんなど）があるので、あえて HTTPS で通信を行うという対策に触れました。
ただ、おっしゃる通り、混乱を招く書き方でした。ユーザがアクセスするフロントエンドWebサーバ自体に HTTPS を導入しても対策にはならないので、「CGI等が外部サーバのAPIから情報を取得する際に HTTPS (TLS) を使用するのも、APIから取得するデータの傍受・改ざんの対策にはなります。ただし、ウェブサーバが悪意のある第三者が Proxy ヘッダで指定したプロキシに接続させられること自体を防ぐことはできません（接続後に証明書のエラーが発生）」と書くべきでした。ご指摘ありがとうございました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
httpoxy 脆弱性への対策 (スコア:5, 参考になる)
HTTPリクエストヘッダーとして送られてきた Proxy が環境変数 HTTP_PROXY にセットされるのが問題なだけなので、リクエストヘッダーの Proxy を落とすだけで対策可能です。
PHPに関するHTTPOXY脆弱性の問題と対応方法 [ichikaway.com] によると、Apache (mod_header が使用可能な場合) なら、
とするだけで対策可能です。RequestHeader ディレクティブ [apache.org] は大文字と小文字は区別しないので、proxy とか proXY が送られてきても大丈夫です。
そのほか、HTTP ではなく HTTPS を使うのも対策になります（不正なプロキシを経由して通信内容が書き換わると証明書のエラーとなるため）。cgi がインターネットを経由して HTTP 通信（平文）で情報を
Re:httpoxy 脆弱性への対策 (スコア:1)
> そのほか、HTTP ではなく HTTPS を使うのも対策になります（不正なプロキシを経由して通信内容が書き換わると証明書のエラーとなるため）
これ、CGI実行プロセスからさらに外部アクセスするときのproxy設定が乗っ取られるわけだから、サーバ自身のHTTPS設定とは関係ないですよね。
確かに、さらに外部アクセスする先のサーバ（攻撃を受けたのとは別のサーバ）がHTTPS化され、証明書の検証を省いていなければエラーになりますが、そちらは外部サーバなわけだから自分ではコントロールできないし、オレオレ証明書で証明書検証を外していたり（内部ネットワーク内でアクセスしている場合）することもままあるわけで、
「HTTP ではなく HTTPS を使うのも対策になります」
と言い方は混乱を招くのでは？
「（攻撃を受ける）サーバでHTTPSを使うのは対策にはならない」のでは？
Re:httpoxy 脆弱性への対策 (スコア:3)
その通りです。
外部サーバを自分で管理していない場合であっても、外部サーバに HTTPS で接続すれば（証明書の検証を行う設定ならば）、不正なプロキシによるデータ改ざんは防げます（正確には改ざんを検知してエラーを発生させることができます。エラーが発生することにより正常なサービスが提供できなくなる問題は残ります）。そのため、今まで cgi から外部APIに HTTP で接続するようにしていた場合、HTTPS 接続に変更するといった対策は有効です。
勿論、接続先のAPI等が HTTP (平文) 接続にしか対応しておらず、HTTPSでの接続を受け付けない場合にはどうしようもないですが、一般公開されているAPIの場合、TLS非対応のAPIは少なくなってきています。
API 等を HTTPS に対応させることは、自分が管理しているサーバじゃないとできないので、「cgi から接続する先のサーバを自分で管理している場合には Let's Encrypt [letsencrypt.jp] や その他の無料SSL/TLS証明書 [jstream.jp] でも構わないので HTTPS にすると良いでしょう」と「自分で管理している場合」に限定する文言を入れました。
「HTTPリクエストヘッダーとして送られてきた Proxy が環境変数 HTTP_PROXY にセットされることを防ぐ」、あるいは「環境変数 HTTP_PROXY を無視する」ことが httpoxy 問題への根本的な対策ではあるのですが、インターネット経由で外部APIと通信する CGI (php を含むWebアプリケーション) が多くなっており、CGIがインターネット経由で外部APIから HTTP (平文) で情報を取得すること自体に別の危険性（通信の傍受・改ざんなど）があるので、あえて HTTPS で通信を行うという対策に触れました。
ただ、おっしゃる通り、混乱を招く書き方でした。ユーザがアクセスするフロントエンドWebサーバ自体に HTTPS を導入しても対策にはならないので、「CGI等が外部サーバのAPIから情報を取得する際に HTTPS (TLS) を使用するのも、APIから取得するデータの傍受・改ざんの対策にはなります。ただし、ウェブサーバが悪意のある第三者が Proxy ヘッダで指定したプロキシに接続させられること自体を防ぐことはできません（接続後に証明書のエラーが発生）」と書くべきでした。ご指摘ありがとうございました。