Does Heartbleed ring a bell? Not the human Heartbleed; but the pun version of it given as a name to a bug that exploited the TLS/SSL heartbeat function to bleed off data from a vulnerable server. If you haven’t heard of Heartbleed, Poodle, Logjam or the dystopian Shellshock may bring back memories. These are all security bugs of course – bugs with impressive names!
Welcome to the list of bugs with impressive names, or rather a welcome back after 15 years – HTTPoxy. Although newly named, the HTTPoxy vulnerability was discovered 15 years ago in 2001. HTTPoxy revolves around HTTP requests and malicious proxy settings. Intended to sound like a disease, the logo of this vulnerability completes the picture.
HTTPoxy is a set of vulnerabilities that affect application code running in CGI—or CGI-like—environments. Server-side web applications are the main points of concern with HTTPoxy.
To quote the official CGI documentation – The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. The interface has been in use by the Worldwide Web (WWW) since 1993.
To put it in simpler terms, this means that if you want features like a search engine or support forum on a web server, then these functions do not need to be written into the web server itself. Using CGI, the web server can send requests to other programs to generate the web content. The results of those programs is then used to create the actual web pages.
Web requests include a number of HTTP headers. These HTTP headers allow information in the form of request and response to be passed between a client and a server. If the server can pass the headers to a different process that handles the CGI work, it makes life even simpler.
HTTPoxy requires the code to be running under a CGI-like context that recognizes HTTP_PROXY and a HTTP client that trusts this HTTP_PROXY. The HTTP client will have to use that HTTP_PROXY variable as the web proxy to run a HTTP request. This is where HTTPoxy vulnerability creates a namespace conflict as disclosed on their website –
- RFC 3875 (CGI) puts the HTTP Proxy header from a request into the environment variables as HTTP_PROXY
- HTTP_PROXY is a popular environment variable used to configure an outgoing proxy
HTTPoxy impacts a range of server software, including PHP, Go, Apache HTTP server, Apache TomCat, PHP-engine HHVM, and Python. The HTTPoxy vulnerability does not allow for remote code execution, however, it does open up web services to man-in-the-middle attack.
Can NetScaler act as a vaccination against the HTTPoxy disease?
In one word, YES!
First, HTTPoxy itself does not affect NetScaler!
Second, NetScaler has multiple features to both protect and block against HTTPoxy attacks.
Here is how you can protect against this vulnerability using NetScaler:
- Drop Requests with Proxy Headers
Use the Responder feature in NetScaler to drop requests with a simple Policy as shown below:
add responder policy httpoxy
2. Drop Proxy Headers
Use the Rewrite feature in NetScaler to drop proxy headers in a request as shown below:
add rewrite action httpoxy_act delete_http_header Proxy
add rewrite policy httpoxPol
3.Block Requests with Proxy Headers
NetScaler AppFirewall can block the Proxy based headers with signatures as shown below:
Protect against HTTPoxy with NetScaler
NetScaler with its powerful tools provides effective means to block and drop an attack from the HTTPoxy vulnerability. Use the above given methods to audit your applications.
Besides the above given methods, you can also use NetScaler to switch from HTTP to HTTPS all over your environment, ensuring safety across multiple different vulnerabilities. Stay safe with complete protection against vulnerabilities with NetScaler.
Blog context courtesy of Lena Yarovaya, Director of Technical Marketing at Citrix