HTTP Parameter Pollution (HPP)

This blog post was written by Rodney Kariuki

Introduction

HTTP Parameter Pollution (HPP) is a type of injection attack that occurs when a target system accepts multiple parameters with the same name and handles them in a manner that might be insecure or unexpected. This type of vulnerability can be found on both the server-side and client-side.

How HPP Works

HPP 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.

When multiple parameters with the same name are sent to a server, different languages and frameworks handle these parameters in a different way. This is because there is no standard way for accepting multiple parameters with the same name.

The table below illustrates how web technologies behave in presence of multiple occurrences of the same HTTP parameter.

Given the URL and query string:

http://example.com/?color=red&color=blue

NB: Unusual behaviours are a usual source of security weaknesses.

By itself, this is not necessarily an indication of vulnerability. However, if the developer is not aware of the problem, the presence of duplicated parameters may produce an anomalous behavior in the application that can be potentially exploited by an attacker.

Testing for HPP Vulnerabilities

Information transfer using the HTTP protocol can be done in various ways, such as:

• • Within the URI – using the GET parameters
  • Within the request body – using the POST parameters
  • In the HTTP headers – using the COOKIE header

These are all valid places to test for HPP vulnerabilities. To proceed with our attack, we will aslo need to:

• • Identify the back-end server and parsing method used (Enumeration is key).
  • Assess injection points and try bypassing input filters using HPP.

Types of HTTP Parameter Pollution Vulnerabilities

1. Client-Side HTTP Parameter Pollution Vulnerability

The HTTP Parameter Pollution (HPP) Client-side attack has to do with the client or user environment, meaning that the user’s actions (i.e., access a link in a browser) are affected and will trigger a malicious or unintended action without the user’s knowledge.

An example of a typical HPP client-side attack includes a website that is vulnerable to HPP and a group of victims that will interact with the vulnerable website. An attacker, after identifying a vulnerable website, will create a vulnerable link with its HTTP parameters polluted and will send this link or make it publicly available through emails or social networks for naive and unsuspecting victims to click on. After the victims have clicked on it, the intended malicious behavior will be performed, affecting the users and the web application (application providers).

2. Server-Side HTTP Parameter Pollution Vulnerability

Objective: Transfer $100 from Jake to Attacker

In the HPP Server-side attack, the back-end environment of the web application will be affected. The attacker using HPP attacks will try to exploit the logic of the vulnerable web application by sending a triggered, or polluted URL, for example to access the database of a web application or perform unintended actions.

We have a payment gateway developed using PHP and running on an Apache Server. We perform a request to the payment gateway which looks as below:

http://payment-gateway:8181/?from=Attacker&to=Jake&amount=100

For security purposes, the from=Attacker parameter is not coming directly from the website itself (because the attacker can modify it). The server uses your cookie to get your username (lookup) and then adds it to the back-end request to the payment-gateway.

So, we know we cannot change the value of the from parameter, but can we sneak in our own values?

Yes, we can!

http://payment-gateway:8181/?from=Attacker&to=Jake&from=Jake&to=Attacker&amount=100

If the server was improperly configured $100 would be taken from Jake’s account and transferred to the user account.

Though this is a very simple example, this is the foundation of Server-Side HPP: looking for different parameters and editing, adding or deleting from a request.

HPP Vulnerabilities in the Wild

A critical HPP vulnerability was discovered in Blogger , the popular blogging platform. The bug allowed malicious users to take ownership of the victim’s blog by using the following HTTP request:

POST /add-authors.do HTTP/1.1

[…]

security_token=attackertoken&blogID=attackerblogidvalue

&blogID=victimblogidvalue

&authorsList=goldshlager19test%40gmail.com(attacker email)

&ok=Invite

The flaw resided in the authentication mechanism used by the web application, as the security check was performed on the first blogID parameter, whereas the actual operation used the second occurrence.

Other HPP vulnerabilities in the wild included:

• Parameter pollution in social sharing buttons- Reported to HackerOn; Bounty: $500.
• Twitter Unsubscribe Notifications- Reported to Twitter; Bounty $700.
• Bypassing Digits web authentication’s host validation with HPP- Reported to: Twitter; Bounty: $2520.

Implications

Whether or not HPP constitutes a serious vulnerability depends on the specific applications code. The impact can range from:

• • Bypassing security control mechanisms e.g. authentication.
  • Bypassing filters e.g. (Web Application Firewall).
  • Change the application flow

Additionally, an attacker can potentially override existing hard-coded HTTP parameters (e.g. prices of items in e-commerce website) to modify the behavior of an application, bypass input validation checks, and access and possibly exploit variables that may be out of direct reach for an attacker. HPP can also be chained with other bugs.

Detection and Mitigations

Detection

• • Use a vulnerability scanner that can be able to detect such attacks.
  • Manual testing.

Mitigation

• Accept parameters only where they are supposed to be supplied.
• Make sure to perform an extensive and proper input validation. All user-supplied data, which is reflected in the HTML source code of the HTTP response, should be encoded according to the context in which they are reflected.
• Configure a WAF to not allow multiple instances of the same parameter in a single HTTP request. This would prevent all types of this attack. However, this might not be possible in all cases, though, as some apps might need multiple duplicate parameters. They might be designed to send and accept multiple HTTP parameters of the same name in the same request.
• HTTP Parameter Pollution server side, it’s always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end to avoid special characters that may be used for HPP attacks
• From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc to avoid special characters that may be used for HPP attacks.

References

HTTP Parameter Pollution Explained

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution

https://securityintelligence.com/posts/how-to-prevent-http-parameter-pollution/

https://www.acunetix.com/blog/whitepaper-http-parameter-pollution/

https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/http-parameter-pollution/

Disclaimer

The MacroSec blogs are solely for informational and educational purposes. Any actions and or activities related to the material contained within this website are solely your responsibility. The misuse of the information on this website can result in criminal charges brought against the persons in question. The authors and MacroSec will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.