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:
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.
- Barracuda Web Application Firewall (WAF) corporate site
- Barracuda Campus – WAF documentation
- Barracuda WAF risk-free, 30-day evaluation