Saturday , September 18 2021 1:44 AM
Home / Security Guides / How to Protect Your Server Against the HTTPoxy Vulnerability

How to Protect Your Server Against the HTTPoxy Vulnerability

What Is HTTPoxy?

On July 18th, a vulnerability named ‘HTTPoxy’ was announced, affecting some server‑side web applications that run in CGI or CGI‑like environments, such as some FastCGI configurations. Languages known to be affected so far include PHP, Python, and Go.

A number of CVEs have been assigned, covering specific languages and CGI implementations:

The vulnerability exists because of a namespace clash. A CGI or FastCGI‑like interface sets environment variables based on HTTP request parameters, and these can override internal variables that are used to configure the application.

Currently, the only known exploit of this vulnerability is to web applications running in CGI and CGI‑like environments that use certain HTTP client libraries to make HTTP requests to other services. In this case, attackers can potentially redirect internal requests generated by the application to a server of their choosing, and thus capture any secret data contained in the requests, as shown below.

How to Protect Your Server Against the HTTPoxy Vulnerability 1

Vulnerable Servers and Applications

HTTPoxy is a general vulnerability found by many CGI implementations. An application or server can correctly implement the CGI specification and still be vulnerable.

For a deployment to be vulnerable, it must:

  • Use the HTTP_PROXY environmental variable to configure proxy connections: Either in the application code itself or any libraries that are used leverages. This is a fairly standard method of configuring proxy servers using the environment.
  • Make requests to backend services using HTTP: Because the name collision is specific to theHTTP_ prefix, only requests made by the application using HTTP will be affected. Requests using HTTPS or any other protocols are not vulnerable.
  • Operate in a CGI or CGI-like environment: Deployments where client headers are translated intoHTTP_ prefixed environmental variables are vulnerable. Any compliant implementation of CGI or related protocols like FastCGI will do this.

As you can see, a combination of deployment- and application-specific factors are necessary for a deployment to be vulnerable. To test whether your deployment is affected, Luke Rehmann has created a simple site to check publicly accessible sites for vulnerability.

How to Defeat the Vulnerability

Fortunately, HTTPoxy is relatively simple to fix. The vulnerability can be addressed from the web server layer or the application or library:

  • Applications or libraries can ignore the HTTP_PROXY variable when they are in a CGI environment.
  • Applications or libraries can use a different environmental variable to configure proxy connections
  • Web servers or proxies can unset the Proxy header received in client requests

If you are using a vulnerable library, you should mitigate the threat on the server end until patches are available to address the issue. If you are a library or application author and your project relies on theHTTP_PROXY variable to configure a proxy backend, consider using an alternative variable that will not clash when running in a CGI-like environment. Ruby and some other projects use CGI_HTTP_PROXY for this purpose.

Since the Proxy header is not a standard HTTP header, it can be safely ignored in almost all cases. This can be done in the web server or load balancer used to direct requests to the application itself. Because the Proxy HTTP header does not have any standard legitimate purpose, it can almost always be dropped.

Any common web server, load balancer, or proxy can unset the appropriate headers.

Removing the HTTP Proxy Header with Apache

If you are running the Apache HTTP web server, the mod_headers module can be used to unset the header for all requests.

Ubuntu and Debian Servers

To enable mod_headers in Ubuntu or Debian servers, type:

sudo nano /etc/apache2/apache2.conf

Towards the bottom, add:

RequestHeader unset Proxy early

Save and close the file.

Check the configuration for syntax errors:

sudo apache2ctl configtest

Restart the service if no syntax errors are reported:

sudo service apache2 restart

Removing the HTTP Proxy Header with Nginx

In Nginx, mitigation is similarly trivial. You can easily sanitize the environment for any CGI-like environment running on the server or upstream.

On Ubuntu and Debian servers, FastCGI parameters are typically included from either thefastcgi_params or fastcgi.conf files when setting up a FastCGI proxy. You can unset theHTTP_PROXY header in both of these files:

echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

If you are not sourcing one of files when configuring your FastCGI proxies, be sure to include this same line in the proxy location itself:

    location ~ \.php$ {
        . . .
        fastcgi_param HTTP_PROXY "";
        . . .

If you are using Nginx for conventional HTTP proxying, you should clear the HTTP Proxy header as well. HTTP proxying headers are set in the /etc/nginx/proxy_params file. You can add the rule to unset theProxy header to that file by typing:

echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params

Again, if you are not sourcing this file from within your server block configuration, you’ll have to add it in the proxy location itself:

    location /application/ {
        . . .
        proxy_set_header Proxy "";
        . . .

Check for syntax errors by typing:

sudo nginx -t

If no errors are reported, restart the service:

sudo service nginx restart


About GOPU

Technology Enthusiast with a keen eye on the Cyber-security and other tech related developments.

Check Also

RAMBleed Attack – Flip Bits to Steal Sensitive Data from Computer Memory

A team of cybersecurity researchers yesterday revealed details of a new side-channel attack on dynamic …