PHP, Python, etc. web applications break the Remote Agent vulnerability: httpoxy-vulnerability warning-the black bar safety net

ID MYHACK58:62201677434
Type myhack58
Reporter 佚名
Modified 2016-07-31T00:00:00


This is a for PHP, Go, Python, and other languages CGI application vulnerabilities.

httpoxy is a series of effects to CGI or the class CGI to run application vulnerability name. Simple to say, it is a name space conflict.

  • RFC 3 8 7 5 (CGI)is defined from the HTTP request to the Proxy head filled directly into the environment variables HTTP_PROXY way
  • HTTP_PROXY is a common to configure the outgoing proxy environment variables

This defect leads to a remote attack. If you are running a PHP or CGI program, you should immediately seal the baffle Proxy head! Right away! The specific approach see below. httpoxy is a server-side web application vulnerabilities, if you're not in the server-side deployment of these codes, then don't worry.

If my Web application there is this vulnerability?

When one utilizes this vulnerability in the HTTP client initiates a request, it can be done:

  • By your Web application to proxy a request to another URL
  • Directly to get your server to open the specified remote address and port
  • Waste resources of the server for the attacker to access the specified resource

httpoxy vulnerability is very easy to use. Hope the security personnel as soon as possible to scan the vulnerabilities and quick fixes.

What is affected?

The following cases will the presence of the security vulnerability:

  • Code running in the CGI context, so HTTP_PROXY will turn into a real or simulated environment variable
  • A trust HTTP_PROXY the HTTP client, and supports proxy functionality
  • The client will request the inside to initiate an HTTP or HTTPS request

The following case is has been found that the presence of the defects environment:

| 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

Certainly there are many more we did not determine whether there is a defect of the language and the environment.


  • Whether there is a defect depends on your application code and the PHP library, but the impact seems to be very extensive
  • As long as the processing the user request using the one with the defect library may be used
  • If you use the defect library, the defect can affect any PHP version
  • Even affect the alternative PHP runtime environment, such as deployed in FastCGI mode IT
  • Confirm the impact of Guzzle, the Artax and other libraries, there may be many, many libraries are also affected
  • Guzzle 4.0. 0rc2 and later affected, Guzzle 3 and earlier versions are not affected
  • Other examples are Composer StreamContextBuilder tool class

For example, if you're in Drupal using Guzzle 6 module to initiate outgoing requests such as a request to a weather API, the module initiates the request on the existence of this httpoxy defects.


  • Python code is only deployed in CGI mode, only the presence of defects, in General, the presence of defects in the code will be used similar to wsgiref. handlers. CGIHandler CGI Controller
  • The normal way to deploy Python web applications are not affected, most people use WSGI or FastCGI, which of the two is not affected, so affected Python applications than PHP is much less
  • wsgi is not affected, because of the os. environ will not be CGI data pollution
  • The presence of defects in the requests library must trust and use the os. environ['HTTP_PROXY'], and does not do content inspection


  • Go code must be deployed in CGI was affected. In General the affected code will use the net/http/cgi package
  • Like Python, this is not the deployment Go for a Web application the usual way. So affected by the situation rarely
  • In contrast, the Go net/http/fcgi package does not set the actual environment variables, so are not affected
  • The presence of defects in the net/http version is required in the outgoing request in the trust and use the HTTP_PROXY, do not check the contents of the


The best fix is in and they attack your application as early as possible before sealing the baffle Proxy request header. It's very simple, also very safe.

  • Says it is safe is because the IETF does not define the Proxy request header, also not listed in IANA message header registration. This indicates that the head of the using is non-standard, or even temporarily used to
  • Standards compliant HTTP client and server should never be read and sent this to the head
  • You can request to remove the head or simply the entire seal stopper using it's request
  • You can be in the upstream did not release a patch themselves to fix this problem
  • When the HTTP request comes in it checks it, so you can one-time fixing many of the deficiencies of the application
  • In the reverse proxy and application firewall after the application excluding the Proxy request header is secure

How to seal retaining Proxy request header depends on your configuration. The easiest way is in your Web application firewall on the seal baffle of the head, or directly in the Apache and Nginx do. The following are some of the How-to guide:


Use the following statement to the sealing stopper is passed to PHP-FPM, PHP-PM the request header, this statement can be placed in fastcgi. conf or fastcgi_param in as you using which configuration file to:

  1. fastcgi_param HTTP_PROXY "";

In FastCGI mode, the PHP is flawed, but most use Nginx FastCGI the other language is not affected by it.


For Apache affected by the specific degree, as well as other Apache Software projects, such as Tomcat, it is recommended refer to the Apache Software Foundation's official announcement

[1] [2] next