SiteHost
Back to Blog

HTTPoxy and You: A Summary

/ Technical
An old exploit has reappeared - here's what we have done and what you need to know about it.

An older exploit, now being called HTTPoxy has surfaced again on the internet in the last day, affecting a number of server-side software platforms including Apache, Nginx and PHP among others. This exploit, based around malicious manipulation of a Proxy header in a request, was first noted 15 years ago but the impact of it and its presence in modern software has only just been discovered.

In essence (and forgive the technical speak), an attacker can send a false Proxy header in their request to a vulnerable server that then calls an external resource (perhaps an API call of some sort) but instead of sending that request where it is supposed to go, it is instead directed to the proxy server that the attacker provided in the header. This could be used to gather information that wouldn't normally be accessible. It takes advantage of a naming conflict, in that a custom "Proxy" header in a request will be translated into "HTTP_PROXY" - the same name as a common variable used to configure outgoing proxies. In certain configurations this value is implicitly trusted by the application making the external resource request.

HTTPoxy is definitely an issue that you should take seriously, as we do, but in saying that it is important to be aware that the exploit is limited to very specific circumstances and specific configurations. We are taking a proactive approach in mitigating the issue to cover as many possibilities as possible, and we consider this a medium impact exploit that depends highly on the configuration and usage of your particular application.

What is affected?

HTTPoxy only affects server-side applications, so your browser is safe. Many of the most popular webserver applications are affected (Apache and Nginx included) when used in combination with a CGI-loaded processor such as PHP, Python or Go. As of yet not all applications have been tested but due to the nature of the issue it is likely that it affects a large number of systems.

Thankfully, mitigating the issue is fairly simple.

How can we fix it?

If you're using our Cloud Containers product or on managed hosting for our other products, we've already mitigated the issue for you or will be doing so shortly. If you're running an unmanaged system then mitigating the vulnerability will depend on your specific configuration, and involves dropping the Proxy header as soon as possible in the chain, before it reaches your application, either by setting it to blank and letting the request continue or by blocking the request entirely.

We've covered a few of the most common server configurations below:

Apache

If your Apache server is running mod_headers, mitigation can be implemented with a single line in your httpd.conf or apache2.conf file:

RequestHeader unset Proxy early

With mod_security you can add the following line (adjust the action to suit your requirements):

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

NginX

Under Nginx, PHP loaded using FastCGI (such as php-fpm) are vulnerable to the exploit. To drop the Proxy header definition, use the following line in your php-fpm configuration:

fastcgi_param HTTP_PROXY "";

For Nginx as a proxy, you can use the following:

proxy_set_header Proxy "";

Varnish

Add this to the existing vcl_recv section in your configuration:

unset req.http.proxy;

HAProxy

Removing the header from requests with HAProxy can be achieved with:

http-request del-header Proxy

IIS

Microsoft frameworks such as .NET and ASP are not affected by the vulnerability as they aren't loaded via CGI. If however you are loading something via CGI in IIS such as PHP you will be vulnerable. Within ApplicationHost.config you can use the following 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>

Depending on your specific requirements you may want to extend the scope of this rule to <globalRules> instead of <rules>.

For more technical information on the exploit have a look at the official site for HTTPoxy.