PHP 、Python 等网站应用惊爆远程代理漏洞：httpoxy
httpoxy HTTP 安全
![](/data/attachment/album/201607/19/212732vobtmd2b7j3x3z33.jpg)



> 
> 这是一个针对 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 | Guzzle 4+ Artax |
| Python | wsgiref.handlers.CGIHandler twisted.web.twcgi.CGIScript | requests |
| Go | net/http/cgi | net/http |


肯定还有很多我们没有确定是否存在缺陷的语言和环境。


#### PHP


* 是否存在缺陷依赖于你的应用代码和 PHP 库，但是影响面看起来似乎非常广泛
* 只要在处理用户请求的过程中使用了一个带有该缺陷的库，就可能被利用
* 如果你使用了有该缺陷的库，该缺陷会影响任意 PHP 版本
	+ 甚至会影响到替代的 PHP 运行环境，比如部署在 FastCGI 模式下的 HHVM
* 确认影响 Guzzle、Artax 等库，可能还有很多很多的库也受影响
	+ Guzzle 4.0.0rc2 及其以后版本受影响，Guzzle 3 及更低版本不受影响
	+ 其它的例子还有 Composer 的 StreamContextBuilder 工具类


举个例子说，如果你在 Drupal 中使用 Guzzle 6 模块发起外发请求（比如请求一个天气 API），该模块发起的请求就存在这个 httpoxy 缺陷。


#### Python


* Python 代码只有部署在 CGI 模式下才存在缺陷，一般来说，存在缺陷的代码会使用类似 `wsgiref.handlers.CGIHandler` 的 CGI 控制器
	+ 正常方式部署的 Python web 应用不受影响（大多数人使用 WSGI 或 FastCGI，这两个不受影响），所以受到影响的 Python 应用要比 PHP 少得多
	+ wsgi 不受影响，因为 os.environ 不会受到 CGI 数据污染
* 存在缺陷的 requests 库必须信任和使用 `os.environ['HTTP_PROXY']`，并且不做内容检查


#### Go


* Go 代码必须部署在 CGI 下才受影响。一般来说受到影响的代码会使用 `net/http/cgi` 包
	+ 像 Python 一样，这并不是部署 Go 为一个 Web 应用的通常方式。所以受到影响的情形很少
	+ 相较而言，Go 的 `net/http/fcgi` 包并不设置实际的环境变量，所以不受影响
* 存在缺陷的 `net/http` 版本需要在外发请求中信任并使用 `HTTP_PROXY` ，并不做内容检查


### 马上修复


最好的修复方式是在他们攻击你的应用之前尽早封挡 `Proxy` 请求头部。这很简单，也很安全。


* 说它安全是因为 IETF 没有定义 `Proxy` 请求头部，也没有列在 [IANA 的消息头部注册](http://www.iana.org/assignments/message-headers/message-headers.xhtml)中。这表明对该头部的使用是非标准的，甚至也不会临时用到
* 符合标准的 HTTP 客户端和服务器绝不应该读取和发送这个头部
* 你可以从请求中去掉这个头部或者干脆整个封挡使用它的请求
* 你可以在上游没有发布补丁时自己来解决这个问题
	+ 当 HTTP 请求进来时就检查它，这样可以一次性修复好许多存在缺陷的应用
	+ 在反向代理和应用防火墙之后的应用剔除 `Proxy` 请求头部是安全的


如何封挡 `Proxy` 请求头部依赖于你的配置。最容易的办法是在你的 Web 应用防火墙上封挡该头部，或者直接在 Apache 和 Nginx 上做也行。以下是一些如何做的指导：


#### Nginx/FastCGI


使用如下语句封挡传递给 PHP-FPM、PHP-PM 的请求头，这个语句可以放在 fastcgi.conf 或 fastcgi\_param 中（视你使用了哪个配置文件）：



```
fastcgi_param HTTP_PROXY "";

```

在 FastCGI 模式下，PHP 存在缺陷（但是大多数使用 Nginx FastCGI 的其它语言则不受影响）。


#### Apache


对于 Apache 受影响的具体程度，以及其它的 Apache 软件项目，比如 Tomcat ，推荐参考 [Apache 软件基金会的官方公告](https://www.apache.org/security/asf-httpoxy-response.txt)。 以下是一些主要信息：


如果你在 Apache HTTP 服务器中使用 `mod_cgi`来运行 Go 或 Python 写的脚本，那么它们会受到影响（这里 `HTTP_PROXY` 环境变量是“真实的”）。而 `mod_php` 由于用于 PHP 脚本，也存在该缺陷。


如果你使用 **mod\_headers** 模块，你可以通过下述配置在进一步处理请求前就 unset 掉 `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 的话，它本身不受影响。不过你可以用它来剔除掉 Proxy 请求头部，以保护其后面的其它服务。具体可以参考 [ASF 指导](https://www.apache.org/security/asf-httpoxy-response.txt)。


#### HAProxy


通过下述配置剔除该请求头部：



```
http-request del-header Proxy

```

#### Varnish


通过下述语句取消该头部，请将它放到已有的 vcl\_recv 小节里面：



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

```

#### OpenBSD relayd


使用如下语句移除该头部。把它放到已有的过滤器里面：



```
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` 以加载 `mod_magnet` 模块，并运行如上 lua 代码：



```
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 在 curl 中发现该缺陷并修复。


2012 年 7 月
在`Net::HTTP` 的 `HTTP_PROXY` 实现中， Ruby 团队的 Akira Tanaka 发现了该缺陷


2013 年 11 月
在 nginx 邮件列表中提到了该缺陷。发现者 Jonathan Matthews 对此不太有把握，不过事实证明他是对的。


2015 年 2 月
Stefan Fritsch 在 Apache httpd-dev 邮件列表中提到了它。


2016 年 7 月
Vend 安全团队的 Scott Geary 发现了对该缺陷，并且它影响到了 PHP 等许多现代的编程语言和库。



所以，这个缺陷已经潜伏了许多年，许多人都在不同方面发现了它的存在，但是没有考虑到它对其它语言和库的影响。安全研究人员为此专门建立了一个网站： <https://httpoxy.org/> ，可以在此发现更多内容。


 


OK
*httpoxy* is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes
down to a simple namespace conflict:

`Proxy`

header from a request into the environment variables as `HTTP_PROXY`

`HTTP_PROXY`

is a popular environment variable used to configure an outgoing proxyThis leads to a remotely exploitable vulnerability. If you’re running PHP or CGI, you should block the `Proxy`

header.
[Here’s how.](#fix-now)

httpoxy is a vulnerability for server-side web applications. If you’re not deploying code, you don’t need to worry.

If a vulnerable HTTP client makes an outgoing HTTP connection, while running in a server-side CGI application, an attacker may be able to:

httpoxy is extremely easy to exploit in basic form. And we expect security
researchers to be able to scan for it quickly. Luckily, if you read on and
find you are affected, [easy mitigations](#fix-now) are available.

httpoxy **was disclosed in mid-2016**. If you’re reading about it now for the first time, you can *probably* relax and
take your time reading about this quaint historical bug that *hopefully* no longer affects any of the applications you
maintain. But you should verify that to your own satisfaction.

The content below this point reflects the original disclosure, and I’ll be leaving the site up and mostly unchanged, other than noting fix versions where I can. I guess I’m just saying: the time for urgency was last year.

A few things are necessary to be vulnerable:

`HTTP_PROXY`

becomes a real or emulated environment variable`HTTP_PROXY`

, and configures it as the proxyFor example, the confirmed cases we’ve found so far:

Language | Environment | HTTP client |
---|---|---|

PHP | php-fpm mod_php |
Guzzle 4+ Artax |

Python | wsgiref.handlers.CGIHandler twisted.web.twcgi.CGIScript |
requests |

Go | net/http/cgi | net/http |


But obviously there may be languages we haven’t considered yet. CGI is a common standard, and
`HTTP_PROXY`

seems to be becoming more popular over time. Take the below as a sample of the most
commonly affected scenarios:

`>=4.0.0rc2,<6.2.1`

are vulnerable, Guzzle 3 and below is not.So, for example, if you are using a Drupal module that uses Guzzle `6.2.0`

and makes an outgoing HTTP request (for example,
to check a weather API), you are vulnerable to the request that plugin makes being “httpoxied”.

`wsgiref.handlers.CGIHandler`

`os.environ['HTTP_PROXY']`

, without checking if CGI is in use`2.7.13`

, `3.4.6`

, `3.5.3`

, `3.6.0`

(see `net/http/cgi`

package.
`net/http/fcgi`

package, by comparison, does not set actual environment variables, so it is `net/http`

will trust and use `HTTP_PROXY`

for outgoing requests, without checking if CGI is in use`1.7rc3`

, all stable versions of `>=1.7`

The best immediate mitigation is to block `Proxy`

request headers as early as possible, and before they hit your
application. This is easy and safe.

`Proxy`

header is undefined by the IETF, and isn’t listed on the
`Proxy`

header is safe!How you block a `Proxy`

header depends on the specifics of your setup. The earliest convenient place to block the header
might be at a web application firewall device, or directly on the webserver running Apache or NGINX. Here are a few of
the more common mitigations:

Use this to block the header from being passed on to PHP-FPM, PHP-PM etc.

```
fastcgi_param HTTP_PROXY "";
```


In FastCGI configurations, PHP is vulnerable (but many other languages that use NGINX FastCGI are not).

For specific NGINX coverage, we recommend that you read the official [NGINX blog post](https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx)
on this vulnerability. The blog post provides a graphic depiction of how
httpoxy works and more extensive mitigation information for NGINX.

For specific Apache coverage (and details for other Apache software projects like Tomcat), we strongly recommend
you read the [Apache Software Foundation’s official advisory](https://www.apache.org/security/asf-httpoxy-response.txt) on
the matter. The very basic mitigation information you’ll find below is covered in much greater depth there.

If you’re using Apache HTTP Server with `mod_cgi`

, languages like Go and Python may be vulnerable (the `HTTP_PROXY`

env var
is “real”). And `mod_php`

is affected due to the nature of PHP. If you are using **mod_headers**, you can unset the
`Proxy`

header before further processing with this directive:

```
RequestHeader unset Proxy early
```


Example for using this in `.htaccess`

files:

```
<IfModule mod_headers.c>
RequestHeader unset Proxy
</IfModule>
```


If you are using **mod_security**, you can use a `SecRule`

to deny traffic with a `Proxy`

header. Here’s an example,
vary the action to taste, and make sure `SecRuleEngine`

is on. The 1000005 ID has been assigned to this issue.

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


Finally, if you’re using Apache Traffic Server, it’s not itself affected, but you can use it to strip the `Proxy`

header; very helpful
for any services sitting behind it. Again, see the [ASF’s guidance](https://www.apache.org/security/asf-httpoxy-response.txt),
but one possible configuration is:

Within `plugin.config`

, inside the configuration directory (e.g. `/usr/local/etc/trafficserver`

or `/etc/trafficserver`

),
add the following directive:

```
header_rewrite.so strip_proxy.conf
```


Add the following to a new file named `strip_proxy.conf`

in the same directory:

```
cond %{READ_REQUEST_HDR_HOOK}
rm-header Proxy
```


This will strip the header off requests:

```
http-request del-header Proxy
```


If your version of HAProxy is old (i.e. `1.4`

or earlier), you may not have the `http-request del-header`

directive.
If so, you must also take care that headers are stripped from requests served after the first one over an HTTP 1.1
keep-alive connection. (i.e. take special note of the limitation described in the first paragraph of [the 1.4 “header
manipulation” documentation](https://cbonte.github.io/haproxy-dconv/1.4/configuration.html#6))

For Varnish, the following should unset the header. Add it to the pre-existing vcl_recv section:

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


For relayd, the following should remove the header. Add it to a pre-existing filter:

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


To reject requests containing a `Proxy`

header

Create `/path/to/deny-proxy.lua`

, read-only to lighttpd, with the content:

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


Modify `lighttpd.conf`

to load `mod_magnet`

and run the above lua code:

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


To strip the `Proxy`

header from the request, add the following to `lighttpd.conf`

:

```
req_header.remove "Proxy";
```


For detailed information about mitigating httpoxy on IIS, you should
head to the official [Microsoft article KB3179800](https://support.microsoft.com/en-us/kb/3179800), which covers
the below mitigations in greater detail.

Also important to know: httpoxy does not affect any Microsoft Web Frameworks, e.g. not ASP.NET nor Active Server Pages.
But if you have installed PHP or any other third party framework on top of IIS, we recommend applying mitigation steps
to protect from httpoxy attacks. You can either block requests containing a `Proxy`

header, or clear the header. (The header
is safe to block, because browsers will not generally send it at all).

To *block* requests that contain a `Proxy`

header (the preferred solution), run the following command line.

```
appcmd set config /section:requestfiltering /+requestlimits.headerLimits.[header='proxy',sizelimit='0']
```


**Note:** `appcmd.exe`

is not typically in the path and can be found in the `%systemroot%\system32\inetsrv`

directory

To *clear* the value of the header, use the following URL Rewrite rule:

```
<system.webServer>
<rewrite>
<rules>
<rule name="Erase HTTP_PROXY" patternSyntax="Wildcard">
<match url="*.*" />
<serverVariables>
<set name="HTTP_PROXY" value="" />
</serverVariables>
<action type="None" />
</rule>
</rules>
</rewrite>
</system.webServer>
```


**Note:** URL Rewrite is a downloadable add-in for IIS and is not included in a default IIS installation.

You can block any request containing a `Proxy`

header (or ban the sending client) via the UrlToolkit:

```
UrlToolkit {
ToolkitID = block_httpoxy
Header Proxy .* DenyAccess
}
```


See more information at the [hiawatha blog](https://www.hiawatha-webserver.org/weblog/115)

Upgrade to `>= 5.0.19`

or `>= 5.1.7`

to mitigate. You can do this manually with one of these commands, or you’ll get
an upgrade notification soon.

```
/usr/local/lsws/admin/misc/lsup.sh -v 5.0.19 # or
/usr/local/lsws/admin/misc/lsup.sh -v 5.1.7
```


See more information at the [litespeed blog](http://blog.litespeedtech.com/2016/07/18/the-httpoxy-vulnerability-has-been-taken-care-of-by-litespeed-automatically/)

Upgrade to `>= 2.0.2`

and add this to your configuration:

```
setenv:
HTTP_PROXY: ""
```


More information can be found in this [GitHub pull request](https://github.com/h2o/h2o/pull/996).

Please let us know of other places where httpoxy is found. We’d be happy to help you communicate fixes for your platform,
server or library if you are affected. Contact [contact@httpoxy.org](mailto:contact@httpoxy.org?subject=Fix) to let us
know. Or create a PR or issue against the [httpoxy-org repo](https://github.com/httpoxy/httpoxy-org) in GitHub.

Userland PHP fixes don’t work. Don’t bother:

`unset($_SERVER['HTTP_PROXY'])`

does not affect the value returned from `getenv()`

, so is not an effective
mitigation`putenv('HTTP_PROXY=')`

does not work either (to be precise: it only works if that value is coming from an
actual environment variable rather than a header – so, it cannot be used for mitigation)`CGI_HTTP_PROXY`

to set the proxy for a CGI application’s internal requests, if necessary
`HTTP_PROXY`

, but you must assert that CGI is not in use`PHP_SAPI == 'cli'`

Otherwise, a simple check is to not trust `HTTP_PROXY`

if `REQUEST_METHOD`

is also set. RFC 3875 seems to require
this meta-variable:

The

`REQUEST_METHOD`

meta-variable MUST be set to the method which should be used by the script to process the request

`HTTP_PROXY`

Under CGITo put it plainly: there is no way to trust the value of an `HTTP_`

env var in a CGI environment. They cannot be
distinguished from request headers according to the specification. So, *any* usage of `HTTP_PROXY`

in a CGI context is
suspicious.

If you need to configure the proxy of a CGI application via an environment variable, use a variable name that will
never conflict with request headers. That is: one that does not begin with `HTTP_`

. We strongly recommend you go for
`CGI_HTTP_PROXY`

. (As seen in Ruby and libwww-perl’s mitigations for this issue.)

CLI-only code may safely trust `$_SERVER['HTTP_PROXY']`

or `getenv('HTTP_PROXY')`

. But bear in mind that code written
for the CLI context often ends up running in a SAPI eventually, particularly utility or library code. And, with open
source code, that might not even be your doing. So, if you are going to rely on `HTTP_PROXY`

at all, you should guard
that code with a check of the `PHP_SAPI`

constant.

A defense-in-depth strategy that can combat httpoxy (and entire classes of other security problems) is to severely restrict
the outgoing requests your web application can make to an absolute minimum. For example, if a web application is
firewalled in such a way that it *cannot* make outgoing HTTP requests, an attacker will not be able to receive
the “misproxied” requests (because the web application is prevented from connecting to the attacker).

And, of course, another defense-in-depth strategy that works is to use HTTPS for internal requests, not just for
securing your site’s connections to the outside world. HTTPS requests aren’t affected by `HTTP_PROXY`

.

Using PHP as an example, because it is illustrative. PHP has a method called `getenv()`

1.

There is a common vulnerability in many PHP libraries and applications, introduced by confusing
`getenv`

for a method that only returns environment variables. In fact, getenv() is closer to the
`$_SERVER`

superglobal: it contains both environment variables and user-controlled data.

Specifically, when PHP is running under a CGI-like server, the HTTP request headers (data supplied
by the client) are merged into the `$_SERVER`

superglobal under keys beginning with `HTTP_`

. This is
the same information that `getenv`

reads from.

When a user sends a request with a `Proxy`

header, the header appears to the PHP application as `getenv('HTTP_PROXY')`

.
Some common PHP libraries have been trusting this value, even when run in a CGI/SAPI environment.

Reading and trusting `$_SERVER['HTTP_PROXY']`

is exactly the same vulnerability, but tends to happen much less often
(perhaps because of getenv’s name, perhaps because the semantics of the `$_SERVER`

superglobal are better understood among
the community).

Note that these examples require deployment into a vulnerable environment before there is actually a vulnerability
(e.g. php-fpm, or Apache’s `ScriptAlias`

)

```
$client = new GuzzleHttp\Client();
$client->get('http://api.internal/?secret=foo')
```


```
from wsgiref.handlers import CGIHandler
def application(environ, start_response):
requests.get("http://api.internal/?secret=foo")
CGIHandler().run(application)
```


```
cgi.Serve(
http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
res, _ := http.Get("http://api.internal/?secret=foo")
// [...]
```


More complete PoC repos (using Docker, and testing with an actual listener for the proxied request) have been prepared
under the [httpoxy Github organization](https://github.com/httpoxy).

Under the CGI spec, headers are provided mixed into the environment variables. (These are formally known as
“Protocol-Specific Meta-Variables” 2). That’s just the way the spec works, not a failure or bug.

The goal of the code, in most of the vulnerabilities, is to find the correct proxy to use, when auto-configuring a
client for the internal HTTP request made shortly after. This task in Ruby could be completed by
the `find_proxy`

method of `URI::Generic`

, which notes:


`http_proxy`

and`HTTP_PROXY`

are treated specially under the CGI environment, because`HTTP_PROXY`

may be set by Proxy: header. So`HTTP_PROXY`

is not used.`http_proxy`

is not used too if the variable is case insensitive.`CGI_HTTP_PROXY`

can be used instead.

Other instances of the same vulnerability are present in other languages. For example, when
using Go’s `net/http/cgi`

module, and deploying as a CGI application. This indicates the vulnerability
is a standard danger in CGI environments.

This bug was first discovered over 15 years ago. The timeline goes something like:

The issue is discovered in libwww-perl and fixed. Reported by Randal L. Schwartz. [3](#fn:perl-bug)

The issue is discovered in curl, and fixed there too (albeit probably not for Windows). Reported by Cris Bailiff. [4](#fn:curl-bug)

In implementing `HTTP_PROXY`

for `Net::HTTP`

, the Ruby team notice and avoid the potential issue. Nice work Akira Tanaka! [5](#fn:ruby-ref)

The issue is mentioned on the NGINX mailing list. The user humbly points out the issue: “unless
I’m missing something, which is very possible”. No, Jonathan Matthews, you were exactly right! [6](#fn:nginx-ref)

The issue is mentioned on the Apache httpd-dev mailing list. Spotted by Stefan Fritsch. [7](#fn:apache-ref)

Scott Geary, an engineer at Vend, found an instance of the bug in the wild. The Vend security team found the vulnerability was still exploitable in PHP, and present in many modern languages and libraries. We started to disclose to security response teams.

So, the bug was lying dormant for years, like a latent infection: pox. We imagine that many people may have found the issue over
the years, but never investigated its scope in other languages and libraries. If you’ve found a historical discussion
of interest that we’ve missed, let us know. You can contact [contact@httpoxy.org](mailto:contact@httpoxy.org?subject=History)
or create an issue against the [httpoxy-org repo](https://github.com/httpoxy/httpoxy-org).

httpoxy has a number of CVEs assigned. These cover the cases where

`Proxy`

header available in such a way that the application cannot tell whether
it is a real environment variable, or`HTTP_PROXY`

environment variable by default in a CGI environment (but only where that application should have been
able to tell it came from a request)The assigned CVEs so far:

We suspect there may be more CVEs coming for httpoxy, as less common software is checked over. If you want to get a CVE assigned for an httpoxy issue, there are a couple of options:

We’ll be linking to official announcements from affected teams here, as they become available.

Over the past two weeks, the Vend security team worked to disclose the issue responsibly to as many affected parties as we could. We’d like to thank the members of:

There’s an [extra](extra.html) page with some meta-discussion on the whole named disclosure thing and contact details.
The content on this page is licensed as [CC0](http://creativecommons.org/publicdomain/zero/1.0/) (TL;DR: use what you
like, no permission/attribution necessary).

I’ve put together some more opinionated notes on httpoxy on [my Medium account](https://medium.com/@nzdominic).

Regards,

Dominic Scheirlinck and the httpoxy disclosure team

July 2016

You can email [contact@httpoxy.org](mailto:contact@httpoxy.org?subject=Fix), or, for corrections or suggestions,
feel free to open an issue on the [httpoxy-org repo](https://github.com/httpoxy/httpoxy-org).

Page updated at 2017-06-23 14:17 UTC

The fix applied correctly handles cases with case-insensitive environment variables.
[libwww-perl-5.51 announcement](http://www.nntp.perl.org/group/perl.libwww/2001/03/msg2249.html) [↩](#fnref:perl-bug)

The [fix applied to Curl](https://sourceforge.net/p/curl/bugs/66/) does not
correctly handle cases with case-insensitive environment variables - it specifically mentions the fix would not
be enough for “NT” (Windows). The commit itself carries the prescient message “[since it might become
a security problem](https://github.com/curl/curl/commit/18f044f19d26f2b6dcd41796966f488a62a1bdca).” [↩](#fnref:curl-bug)

The [mitigation in Ruby](https://bugs.ruby-lang.org/issues/6546), like that for libwww-perl, correctly handles
case-insensitive environment variables. [↩](#fnref:ruby-ref)

The [NGINX mailing list](https://forum.nginx.org/read.php?2,244407,244485#msg-244485) even had a PHP-specific
explanation. [↩](#fnref:nginx-ref)