HTTP Parameter Pollution

In this chapter, we are going to learn about HTTP parameter pollution vulnerabilities.

Type of vulnerability: Client-Side / Server-Side

Chances to find: Common; HPP is part of “Insecure Design” ranked #4 in the “OWASP Top-10 Vulnerabilities“

TL;DR: An HPP vulnerability enables an attacker to send multiple request parameters with the same name to bypass security controls by the target application.

What is HPP?

“HTTP Parameter Pollution tests the applications response to receiving multiple HTTP parameters with the same name; for example, if the parameter username is included in the GET or POST parameters twice.

Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors or modify internal variables values. As HTTP Parameter Pollution (in short HPP) affects a building block of all web technologies, server and client-side attacks exist.”  (src: OWASP)

Let’s have a look at an example. You try to log in to your favourite social media platform. You enter your password and realise that it is incorrect. Next up, you want to reset your password.

An example HTTP request could look like this:

POST /resetPassword HTTP/1.1
Host: example.com
Content-Type: application/xml
Content-Length: 36

emailAddress=regularUser@example.com

Normally, you would then receive an email soon after to your email address with a password reset link.

An attacker could now go ahead and try to pollute the HTTP parameters in a way, so that he receives the victim’s password.

An example HTTP request could look like this:

POST /resetPassword HTTP/1.1
Host: example.com
Content-Type: application/xml
Content-Length: 70

emailAddress=regularUser@example.com&emailAddress=attacker@example.com

The application’s backend could now have different routines running on different servers to check the validity of this request (e.g. does email address exist, create reset token, send token). If those routines read the data from different parameter occurrences (e.g. create token from first occurrence “regularUser”, send token from second occurrence “attacker), an attacker could end up receiving the reset token of the victim.

Let’s look at this table to learn about the different behaviour of interpreting parameters on various web server:

Additional reads:

• OWASP appsec conference presentation on HPP

• Whitepaper on HPP

Impact

The impact of HTTP Parameter Pollution varies heavily depending on the functionality of the target application. Typical exploits include bypasses of WAFs, authentication bypasses and in general bypasses of input validation performed by the app.

Additional write-ups:

• reCAPTCHA bypass by Andres Riancho

• Client-side HPP targeting Yahoo! classic mail by Stefano Di Paola

• User account takeover by Avinash Jain

How to prevent HPP?

The most bulletproof approach would be to check every single request coming in for multiple usages of the same parameter. If this is not feasible, there are additional prevention techniques:

• Make sure that user input is URL-encoded before it is embedded in a URL

• Strict regular expressions must be used for input parameter validation

• Be aware how the backend processes multiple occurrences of a parameter and use the same web server technology all over your app.

Additional resources:

Let’s have a look at a video example of an HPP vulnerability:

This video by PwnFunction gives a very good visual explanation of HPP:

Following links are valuable to learn more about HPP:

• HTTP parameter pollution testing guide by OWASP