Is Your PHP Application Vulnerable to the HTTPoxy Security Exploit? - PHP OAuth Library API package blog

What is the HTTPoxy Vulnerability?

As you may know, CGI (Common Gateway Interface) is a specification that defines how Web servers can pass request information to external programs or modules that will handle the HTTP requests and generate the responses.

One of the aspects that the specification defines is that request headers be passed to the request handling programs or Web server modules as variables that the code can use for its own purposes.

Typically those request headers are passed to environment or server variables with names that have the prefix HTTP_ followed by the request header name in upper case and changing dashes - to underscores _ .

So the value of request header named Proxy: leads to set an environment variable named HTTP_PROXY. In PHP scripts can get the value using either $_SERVER['HTTP_PROXY'] or GetEnv('HTTP_PROXY') .

The problem with this is that some libraries check an environment variable with that same name HTTP_PROXY to send HTTP requests to other servers using a proxy server with the URL defined by the variable value.

This means that it is easy to create an exploit to make a Web server script that uses such libraries to send requests to other servers using a given proxy server.

For instance, if you have script that sends a request to a remote API and uses a library that uses the HTTP_PROXY, all the information that you send and receive to the remote API will be passed to the proxy server defined by that variable.

This may leak for instance OAuth client id and secret values or even more sensitive information. Worse could be altering calls to APIs that perform payments or other types of sensitive operations.

Is my PHP Web Application affected by the HTTPoxy vulnerability?

First, if your scripts do not send HTTP requests to remote servers, this vulnerability does not affect your scripts.

In PHP, basically you can send HTTP requests with either the fopen function, fsockopen function or the curl extension functions. None of these functions and extensions use the HTTP_PROXY environment variable directly.

However, you can pass parameters to these functions to set the proxy server through which the HTTP requests should be sent. If you use a PHP library that uses the HTTP_PROXY variable to define the proxy server to send requests, your application is vulnerable to HTTPoxy.

Is the PHP OAuth Library API or the HTTP client class vulnerable to HTTPoxy?

What about other libraries in PHP or other languages?

The HTTPoxy site claims there are some libraries written in PHP or other languages that use the HTTP_PROXY variable. Check that site to see if you are using any those libraries.

If you are using Drupal 8.x, be aware that the Drupal group announced a patch to address this vulnerability.

How to check if my site is vulnerable to HTTPoxy exploit?

There is an experimental site that was created to test sending requests to a given URL of a site to check if it is vulnerable to HTTPoxy.

I have not tried it because I do not use any of the PHP libraries claimed to be vulnerable, but you may want to try it if you are using those libraries in your sites.

How to mitigate the HTTPoxy vulnerability?

In reality the Proxy: header is not defined by the HTTP 1.1 neither by the HTTP 2 protocol specifications. So if there is any site that makes any use of a header with such name, it can only be a custom header. So in general it is safe to discard the Proxy header if it is passed to a Web server.

Web servers in general blindly pass HTTP request headers to CGI programs. Even Web server modules like Apache mod_php consider Proxy a valid request header and so the HTTP_PROXY variable is always passed to PHP scripts.

So one way to mitigate this problem is to use some configuration or Web server module that filters the Proxy request header, so it is not passed to CGI programs or Web server modules. The solution depends on the Web server that you use.

At the time that this article is being written the PHP group did not yet respond to this vulnerability notice but it is possible that in upcoming PHP versions the Proxy header value is filtered before PHP scripts run, so the HTTP_PROXY variable is not set from request header values. For now it is safer to filter with a specific Web server configuration.

Conclusion

In general I would say this vulnerability is of low risk since the libraries claimed to use the HTTP_PROXY variable are not so many. Still I would double check if you could be using any of those libraries in the applications that you developed or third-party applications that you use.

If you found this article useful, please use the buttons above to share it with other Web developers and system administrators. If you have a question or other relevant matter to say, post a comment here.