PHP, Python and other website applications expose remote proxy vulnerability: httpoxy

[Shenzhen] Yuanchuanghui: 5.26pm, the party hall is waiting for you.”

This is a vulnerability targeting CGI applications in PHP, Go, Python and other languages.

httpoxy is the name of a family of vulnerabilities that affect applications that run in a CGI or CGI-like manner. To put it simply, it is a namespace conflict problem.

RFC 3875 (CGI) defines how to Proxydirectly populate environment variables from the header of the HTTP requestHTTP_PROXY
HTTP_PROXYIs an environment variable commonly used to configure outgoing agents

This flaw allows for remote attacks. If you are running a PHP or CGI program, you should block the Proxy header immediately! immediately! See below for specific instructions. httpoxy is a server-side web application vulnerability. If you don't deploy this code on the server side, you don't need to worry.

What happens if my web application has this vulnerability?

When an HTTP client that exploits this vulnerability makes a request, it can:

Proxy requests to other URLs through your web application
Directly ask your server to open the specified remote address and port
Waste server resources and access specified resources for attackers

The httpoxy vulnerability is very easy to exploit. Hopefully security personnel will scan this vulnerability as soon as possible and fix it quickly.

Which ones are affected?

Security vulnerabilities may exist in the following situations:

The code runs in a CGI context, which HTTP_PROXYbecomes a real or simulated environment variable
A trusted HTTP_PROXYHTTP client that supports proxy functionality
The client will initiate an HTTP (or HTTPS) request within the request

The following situations are environments where this flaw has been found:

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

There are certainly many languages and environments that we haven't identified for defects.

PHP

Whether the flaw exists depends on your application code and PHP library, but the impact seems to be very widespread
As long as a library with this flaw is used in the process of processing user requests, it may be exploited
If you use a library with this flaw, the flaw affects any PHP version
- It may even affect alternative PHP runtime environments, such as HHVM deployed in FastCGI mode
It is confirmed that libraries such as Guzzle and Artax are affected, and there may be many more libraries that are also affected.
- Guzzle 4.0.0rc2 and later versions are affected, Guzzle 3 and lower versions are not affected
- Other examples include Composer's StreamContextBuilder utility class

For example, if you use the Guzzle 6 module in Drupal to initiate outbound requests (such as requesting a weather API), the requests initiated by the module will have this httpoxy flaw.

Python

Python code is only defective when deployed in CGI mode. Generally speaking, the defective code uses wsgiref.handlers.CGIHandlera CGI controller like
- Python web applications deployed in the normal way are not affected (most people use WSGI or FastCGI, these two are not affected), so there are far fewer Python applications affected than PHP
- wsgi is not affected because os.environ is not contaminated by CGI data
The flawed requests library must be trusted and used os.environ['HTTP_PROXY'], and does not do content checking

Go

Go code must be deployed under CGI to be affected. Generally affected code will use net/http/cgithe package
- Like Python, this is not the usual way to deploy Go as a web application. So there are very few cases of being affected
- In comparison, Go's net/http/fcgipackage does not set actual environment variables, so it is not affected
The defective net/httpversion needs to be trusted and used in outgoing requests HTTP_PROXY, without content checking

Fix it now

ProxyThe best fix is to block request headers early before they attack your application . It's easy and safe.

It is said to be safe because Proxythe request header is not defined by the IETF and is not listed in the IANA's message header registry . This indicates that the use of this header is non-standard and not even used ad hoc
Standards-conforming HTTP clients and servers should never read or send this header
You can remove this header from the request or block requests using it entirely.
You can fix this yourself if upstream doesn't release a patch
- Checking HTTP requests as they come in can fix many flawed applications at once
- Application culling behind reverse proxies and application firewalls ProxyRequest headers are safe

How to block Proxyrequest headers depends on your configuration. The easiest way is to block this header on your web application firewall, or directly on Apache and Nginx. Here are some pointers on how to do this:

Nginx/FastCGI

Use the following statement to block the request headers passed to PHP-FPM and PHP-PM. This statement can be placed in fastcgi.conf or fastcgi_param (depending on which configuration file you use):

fastcgi_param HTTP_PROXY "";

PHP is defective in FastCGI mode (but most other languages using Nginx FastCGI are not affected).

Apache

For the specific extent of the impact on Apache, as well as other Apache software projects, such as Tomcat, it is recommended to refer to the official announcement of the Apache Software Foundation . Here are some key messages:

If you use the Apache HTTP server mod_cgito run scripts written in Go or Python, then they will be affected (where HTTP_PROXYthe environment variables are "real"). Since mod_phpit is used in PHP scripts, this flaw also exists.

If you use the mod_headers module, you can unset Proxyrequest headers before further processing the request with the following configuration:

RequestHeader unset Proxy early

If you use the mod_security module, you can use a SecRulerule to deny Proxyrequests with request headers. Here's an example, make sure SecRuleEngineit's turned on. You can adjust it according to your own situation.

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

Finally, if you use Apache Traffic Server, it itself is not affected. However, you can use it to remove the Proxy request header to protect other services behind it. Please refer to ASF guidance for details .

HAProxy

Remove the request header through the following configuration:

http-request del-header Proxy

Varnish

To cancel this header, please put it into the existing vcl_recv section:

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

OpenBSD relayd

Use the following statement to remove this header. Put it inside an existing filter:

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

lighttpd （<= 1.4.40）

Bounces Proxyrequests containing headers.

Create a /path/to/deny-proxy.luafile and make it read-only for lighttpd with the following content:

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

Modify lighttpd.confto load mod_magnetthe module and run the lua code above:

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

lighttpd2 (under development)

ProxyStrip headers from requests . Add the following statement to lighttpd.confit:

req_header.remove "Proxy";

Client-side PHP fix has no effect

There are no user-side fixes to resolve the flaw, so don't bother:

Using unset($_SERVER['HTTP_PROXY'])will not affect getenv()the value returned, so it is useless
Using putenv('HTTP_PROXY=')has no effect (putenv can only affect values from actual environment variables, not from request headers)

History of httpoxy

The vulnerability was first discovered 15 years ago.

In March 2001, Randal L. Schwartz discovered this defect in libwww-perl and fixed it.

In April 2001, Cris Bailiff discovered this flaw in curl and fixed it.

The flaw was discovered by Akira Tanaka of the Ruby team in July 2012 in the implementation Net::HTTPofHTTP_PROXY

The flaw was mentioned on the nginx mailing list in November 2013. Discoverer Jonathan Matthews wasn't so sure, but it turns out he was right.

Stefan Fritsch mentioned it in February 2015 on the Apache httpd-dev mailing list.

The flaw was discovered by Scott Geary of the Vend security team in July 2016, and it affects many modern programming languages and libraries such as PHP.

So, this flaw has been dormant for many years, and many people have discovered its existence in different aspects, but have not considered its impact on other languages and libraries. Security researchers have set up a website specifically for this purpose: https://httpoxy.org/ where you can find out more.