Defend Yourself Against HTTProxy Exploit

Sam - February 26, 2017

Defend Yourself Against HTTProxy Exploit

Tutorials

What Is HTTPoxy?

HTTPoxy also known has CGI application vulnerability has been uncovered on July eighteenth, 2016. When reaching backing services, an attacker can trigger vulnerable deployments by passing an HTTP Proxy header with their demand, which will modify the URL utilized by the application.

The CGI speciation requested for client-provided headers to be passed to the environment with an HTTP_ prefix for namespacing. The vulnerability is caused by what is known as a collision between the HTTP_PROXY environmental variable, continually used to indicate the location of a backend proxy service, and the Proxy HTTP client header. In the event that a CGI application or a library uses this variable without extra processing, it could end up utilizing the esteem gave by the client when attempting to connect to the proxy service and this may clash with configuration variables such as HTTP_PROXY which begin with HTTP_.

Since 2001, the HTTPoxy vulnerability has been known in some forms yet never perceive as a cross board issue until recently. Various security vulnerability identifiers have been generated: CVE-2016-5386, CVE-2016-53887, CVE-2016-5388, CVE-2016-1000109, and CVE-2016-1000110 (At the time of this writing, these are reserved, but not filled out) as this vulnerability impacts an assortment of CGI-like implementations. In spite of the fact that it may impact many deployments, relief is quite straight forward and simple.

Vulnerable Servers and Applications

HTTPoxy is found by numerous CGI implementations and is generally vulnerability. A server or application can effectively execute the CGI specification and still be vulnerable.

In order for a deployment to be vulnerable, it must:

Find the perfect Proxy Product.

Proxyrack offers a multiple options to suit most use cases, if you are unsure our 3 Day Trial allows you to test them all.

Security

Residential proxies

Never get blocked, choose your location

View all option available
Vault

Datacenter proxies

Super fast and reliable

View all option available
Try

3 Day Trial

Test all products to find the best fit

View all option available
  • Make use of the HTTP_PROXY environmental variable to configure proxy connections: This is a pretty standard method of configuring proxy servers using the environment. Either in the application codes itself or any libraries that are utilized influence.

  • Make solicitations to backend administration using HTTP: Requests using HTTPS or any other protocols are not vulnerable because the name collision is peculiar to the HTTP_ prefix, the main request made by the application using HTTP will be influenced.

  • Work in a CGI or CGI-like environment: Deployments, where customers headers are converted into HTTP_, prefixed environmental variables are vulnerable. Any consistent usage of CGI or related conventions like Fast CGI will execute this.

To know if your deployment is been affected, Luke Rehmann has developed a simple site to check publicly accessible sites for vulnerability. As you can see, combinations of deployment- and application- particular variables are vital for a deployment to be vulnerable.

Language Specific Information

Since CGI-like deployments are substantially more regular in the PHP ecosystem than in other languages, then PHP applications, in particular, ought to be reviewed. Moreover, the widespread usage of the getenv strategy in popular libraries intensifies this issue, as it is not instantly clear that these will not just configuration variables but will likewise return unsanitized client input. Specific libraries that are as of now influence are Artax, Guzzle (version 4.0.0rc2 and greater), and Composer’s Stream Context Builder class.

If CGI is been used, libraries that naively read the HTTP_PROXY variable without stabilizing their behavior are vulnerable. However, some other languages that are believed to be vulnerable when deployed utilizing CGI were Go and Python and these languages are commonly deployed utilizing other, non-vulnerable strategies

Step by Step Instruction to Defeat the Vulnerability

The vulnerability can be managed by the web server layer or the library or application and luckily, HTTPoxy is generally easy to fix:

  • Web proxies or servers can unset the Proxy header received in client requests

  • Libraries or applications can make use of a different environmental variable to configure proxy connections

  • Libraries or applications can ignore the HTTP_PROXY variable if they are in a CGI environment.

Consider using an alternative variable that will not crash when running in a CGI-like environment if you are a library or application author and your project relies on the HTTP_PROXY variable to configure a proxy backend. Ruby and some other projects use CGI_HTTP_PROXY for this purpose. If you are using a vulnerable library, you ought to ease the risk on the server end until patches are accessible to address the issue.

It’s safe to ignore in most cases if the Proxy header is not a standard HTTP header because the Proxy HTTP header does not have any standard legal purpose, this should be possible in the load balancer or web server used to direct demands to the application itself.

Cut off the HTTP Proxy Header with Apache

The mod_headers module can be used to unset the header for all requests on the off chance that you are running the Apache HTTP web server.

Ubuntu and Debian Servers

To allow mod_headers in Ubuntu or Debian servers, type:

$ sudo a2enmod headers

Thereafter, open the worldwide configuration file:

$ sudo nano /etc/apache2/apache2.conf

Getting to the bottom, include:

/etc/apache2/apache2.conf

Request Header unset Proxy early

Save and close the file.

Check the configuration for syntax errors:

$ sudo apache2ctl configtest

If there are no syntax errors reported, restart the service\

$ sudo service apache2 restart

CentOS and Fedora Servers

By default for conventional installations, the mod_headers module should be enabled. Open the global configuration files to unset the Proxy header:

$ sudo nano /etc/httpd/conf/httpd.conf

Getting to the bottom, add:

/etc/httpd/conf/httpd.conf

Request Header unset Proxy early

Save and close the file when you are done.

Check for syntax errors by typing:

$ sudo apachectl configtest

If there are no syntax errors found, restart the service by typing:

$ sudo service httpd restart

Removing the HTTP Proxy Header with Nginx

In Nginx, you can easily sanitize the environment for any CGI-like environment running on the server or upstream. Moderation is likewise trifling.

Ubuntu and Debian Servers

FastCGI parameters are usually included from either the fastcgi.conf or fastcgi_params files when setting up a FastCGI proxy on Ubuntu and Debian servers. You can unset the HTTP_PROXYheader in both of these records::

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

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

When configuring your FastCGI proxies, if you are not sourcing one of these files, then be sure to add this same line in the proxy location itself:

/etc/nginx/sites-enabled/some_site.conf
. . .

    location ~ \.php$ {

        . . .

        fastcgi_param HTTP_PROXY "";

        . . .

    }

}

Check for syntax errors by typing:

$ sudo nginx -t 

If there are no errors found, restart the service:

$ sudo service nginx restart

CentOS and Fedora Servers

Nginx on CentOS and Fedora also make use of the same fastcgi.conf and fastcgi_params files to configure FastCGI proxying. In both of these files unset the HTTP_PROXY header by typing:

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

$ echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a  /etc/nginx/fastcgi_params

When configuring your FastCGI proxies, if you are not sourcing one of these files, then be sure to add this same line in the proxy location itself:

/etc/nginx/nginx.conf
. . .

    location ~ \.php$ {

        . . .

        fastcgi_param HTTP_PROXY "";

        . . .

    }

}

You should clear the HTTP Proxy header if you make use of Nginx for conventional HTTP proxying. All you need is to add a rule to unset the Proxy header in any location where you are implementing a proxy_pass. You can easily search your configuration directory if you are not sure where proxy_pass is being used:

$ grep -r "proxy_pass" /etc/nginx

Output

/etc/nginx/nginx.conf.default:        #    proxy_pass   http://127.0.0.1;

Like the example above, any results that are not commented should be edited to include proxy_set_header Proxy “”;:

/etc/nginx/nginx.conf
. . .

    location /application/ {

        . . .

        proxy_pass http://127.0.0.1;

        proxy_set_header Proxy "";

        . . .

    }

}

Check for syntax errors by typing:

$ sudo nginx –t

If no errors are found, restart the service:

$ sudo service nginx restart

Removing the HTTP Proxy Header with HAProxy

You can drop Proxy header before forwarding traffic if you are using HAProxy to direct traffic to your application servers.

Open up the /etc/haproxy/haproxy.cfg file for editing:

$ sudo nano /etc/haproxy/haproxy.cfg

In the backend, frontend, or listen sections of your configuration, you can set the http-request directive.

/etc/haproxy/haproxy.cfg
frontend www

    http-request del-header Proxy

    . . .

backend web-backend

    http-request del-header Proxy

    . . .

listen appname 0.0.0.0:80

    http-request del-header Proxy

    . . .

Save and close the file when you are done. These do not need to be set in each of the sections, though it won’t hurt to include them.

Check the syntax by typing:

$ sudo haproxy -c -f /etc/haproxy/haproxy.cfg

If you found no problems, restart the service by typing:

$ sudo service haproxy restart

Conclusion

The HTTPoxy vulnerability has been in existence for a long time and may influence a vast set of applications deployed on the web. Fortunately, it can without much stress easy to fix using the header-altsering capabilities local to any web server.

Find the perfect Proxy Product.

Proxyrack offers a multiple options to suit most use cases, if you are unsure our 3 Day Trial allows you to test them all.

Security

Residential proxies

Never get blocked, choose your location

View all option available
Vault

Datacenter proxies

Super fast and reliable

View all option available
Try

3 Day Trial

Test all products to find the best fit

View all option available

Daniel - May 9, 2022

How To Create A Custom SEO Tool

Tutorials
Read Article

Daniel - May 9, 2022

Best Proxies For Enterprises

Tutorials
Read Article

Daniel - April 7, 2022

What Is Autofill Magic?

Tutorials
Read Article

Daniel - April 1, 2022

What Is AdsPower Browser?

Tutorials
Read Article

Get Started by signing up for a Proxy Product

View Plans