How to protect yourself from the httpoxy vulnerability

Another day, another name: this time it’s httpoxy.  In certain web server configurations, this vulnerability allows malicious users to intercept internal communications between servers or cause denial-of-service by overloading server resources.  At its core, httpoxy is a simple naming conflict between two unrelated entities: an HTTP header and an environment variable.

How it Works

When a web browser sends a request to a web server, it includes a number of headers that specify information about the request.  For example, browsers may send the “Accept-Language” header to tell the server to return content in a certain language if it’s available, or the “Cookie” header to pass any cookies the browser holds on to the server.  Another one of those possible headers is named “Proxy.”  Vulnerable server configurations will copy some of these headers into environment variables with an “HTTP” prefix, so that the web application code can easily access them.  For example, the “Proxy” header will be copied into an environment variable named “HTTP_PROXY”.  This is where the problem lies: the “HTTP_PROXY” environment variable is actually commonly used for an entirely different purpose: configuring HTTP proxy settings.  This configuration is not something that web clients should ever be able to configure, but with this vulnerability, they can do exactly that.

An example of a worst case scenario exploit is where the user accesses a web application which then calls out to an internal web service to retrieve some information.  In that internal call between applications, it is likely that authentication data such as passwords are passed back and forth; however, users cannot usually see the passwords:

However, in vulnerable environments, the user can actually tell the web server to proxy its outgoing requests through a server of the user’s choosing; that is, the user can instruct the web server to send all its outgoing requests to a certain server instead of directly to their destinations.  Here’s how that would look:

As you can see, the internal request is now sent to the user-controlled proxy server instead of the internal service, including any passwords contained in it.  Depending on the details of the case, the user may be able to use these passwords to gain unauthorized access to internal databases or files, with disastrous consequences.

Protect Yourself

Protecting yourself from httpoxy is very easy if you have a Barracuda Web Application Firewall: simply add a Header Deny Rule.  Specify a header name of “Proxy” and a Maximum Header Value Length of 0.  This will block the Proxy header if it contains anything other than a blank string, preventing users from controlling your server’s proxy settings.  You can add a Header Deny Rule on the Websites->Allow/Deny screen, available on all Web Application Firewall models.

Because the Proxy header is non-standard and is not legitimately used, you can apply this fix everywhere, even on environments that are not vulnerable, without any consequences.  It is easiest and fastest to simply apply the fix instead of trying to investigate which (if any) of your servers are vulnerable.  This will also protect you if you deploy vulnerable servers in the future.

Ressources supplémentaires

• Barracuda Web Application Firewall (WAF) corporate site
• Barracuda Campus – WAF documentation
• Barracuda WAF risk-free, 30-day evaluation