What is HTTP Parameter Pollution?
HTTP Parameter Pollution (HPP) is an attack evasion technique that allows an attacker to craft an HTTP request to manipulate or retrieve hidden information.
This technique is based on splitting an attack vector between multiple instances of a parameter with the same name. Since none of the relevant HTTP RFCs define the semantics of HTTP parameter manipulation, each web application delivery platform may deal with it differently.
Some environments process such requests by linking together the values taken from all instances of a parameter name within the request. The attacker abuses this behavior to bypass pattern-based security mechanisms.
How does HTTP Parameter Pollution Work?
HPP exploits the ambiguity in handling HTTP requests where multiple parameters share the same name. The attacker sends an HTTP request with duplicated parameter names, each containing a portion of the malicious code. The server’s processing of these requests depends on its configuration and the specific web application framework.
Some servers group the values of parameters with the same name, effectively reassembling the malicious code on the server side. Other servers might use only the first or the last instance of a duplicated parameter, which can be exploited to hide the malicious parameter values behind benign ones.
This ability to split and hide malicious code within seemingly harmless parameters makes HPP a particularly stealthy technique for conducting attacks. It can bypass traditional security mechanisms, such as a web application firewall (WAF) and intrusion detection system, that rely on identifying known malicious patterns. The HPP technique can manipulate the application’s behavior, leading to unauthorized data access, information disclosure, or even remote code execution.
Example of HTTP Parameter Pollution
Let’s consider a scenario where a web application uses a parameter to redirect users to a specified URL. The valid request URL might look something like this:
http://example.com/home?redirectURL=internalPage
Here, the `redirectURL` parameter is expected to contain the URL of an internal page where the user will be redirected.
An attacker can manipulate this by sending a polluted request, with the parameter appearing twice:
http://example.com/home?redirectURL=internalPage&redirectURL=http://malicious.com
In this case, the application’s handling of the repeat `redirectURL` parameter can lead to an unintended outcome as a result of HPP. Some servers concatenate the parameter values, potentially opening up a loophole where the user may be redirected to the malicious external website instead of the intended internal page. Thus, HPP allows the attacker to manipulate the request and bypass security mechanisms.
Understanding HTTP Parameters
HTTP parameters are part of an HTTP request that carries client-side data to the server. They are an essential aspect of HTTP communication and allow the client to customize a request with additional information, like user-input data.
Below are several different types of HTTP parameters:
GET Requests
GET requests retrieve information from a server using a given URL. The parameters in a GET request are appended to the URL. They are included as key-value pairs separated by an equal sign, while an ampersand separates each pair. A question mark precedes the entire string of parameters. For example, in the URL `http://example.com?page=1`, `page=1` is a GET parameter.
To better illustrate the concept, let’s consider an example. Suppose we have an online bookstore and want to retrieve a specific book’s details. The GET request might look something like this:
http://bookstore.com/books?title=ToKillAMockingbird&author=HarperLee
In this example, `http://bookstore.com/books` is the URL to which the request is made. The question mark `?` indicates the start of the parameters. Two parameters are included in this GET request: `title` and `author`. The value of `title` is `ToKillAMockingbird`, and the value of `author` is `HarperLee`. An ampersand separates these parameters `&`.
This GET request asks the server to retrieve the book “To Kill a Mockingbird” by Harper Lee.
POST Requests
POST requests send data to a server to create/update a resource. Unlike GET parameters, POST parameters are sent in the body of the HTTP request, not in the URL. They are typically used for sending large amounts of data, including files, and for data that needs to be secure, like user passwords.
A typical example of a POST request would be creating a new user in a system. If we continue with the online bookstore analogy, suppose we want to add a new user to the system with the username `BookLover101` and password `SecretPassword`.
The POST request might look like this, sent to the URL `http://bookstore.com/users`:
POST /users HTTP/1.1 Host: bookstore.com Content-Type: application/x-www-form-urlencoded Content-Length: length username=BookLover101&password=SecretPassword
In this example, the first line, `POST /users HTTP/1.1` indicates a POST request. The `Host` is where the request is being sent. The `Content-Type` tells the server what data is being sent (in this case, form data), and `Content-Length` specifies how long the body data is.
Following the header is a blank line, then the request’s body. The body contains the POST parameters `username` and `password`, with their respective values `BookLover101` and `SecretPassword`. These are encoded the same way as GET parameters: key-value pairs separated by an equal sign and each pair separated by an ampersand. The server will interpret this request as a command to create a new user with the given username and password.
PUT/PATCH Requests
PUT and PATCH requests are similar to POST requests. They also send data in the request’s body. However, they are used for updating existing resources. PUT requests replace the entire resource with the provided data, while PATCH requests only alter the parts specified in the parameters.
DELETE Requests
DELETE requests are used to remove a specific resource. They only require the resource identifier as a parameter, typically appended to the URL, similar to GET requests.
Mitigating HTTP Parameter Pollution Attacks
Mitigating HTTP Parameter Pollution (HPP) attacks involves careful coding practices, strict parameter validation, and employing updated security mechanisms. Here are some strategies to consider:
- Accept Known Parameters Only: Ensure your application only accepts the expected parameters. Unrecognized parameters should be treated as an anomaly, resulting in an error or the request being ignored.
- Strict Parameter Validation: Validate all input for type, format, and range. If a parameter is expected to be a number, all non-numeric input should be rejected.
- Single Parameter Instances: Design your application to accept only the first instance of a parameter. Any additional instances should be ignored. This can prevent an attacker from using the same parameter multiple times to exploit HPP.
- Input Sanitization: Implement a robust input sanitization routine. This will help to strip out any potentially harmful strings from user input.
- Use of Security Headers: Consider using security headers like Content Security Policy to mitigate the risk of code injection attacks.
- Update Security Mechanisms: Regularly update web application firewalls, intrusion detection systems, and other security defenses. Updated systems are more likely to recognize and block new forms of attacks.
- Regular Code Review: Regular code reviews can help identify and patch potential vulnerabilities before they can be exploited.
Mitigating HTTP Parameter Pollution with Imperva
Imperva Web Application Firewall (WAF) stops malicious attacks with near-zero false positives, while a global SOC ensures your organization is protected from the latest attacks minutes after they are discovered in the wild.
By applying HTTP protocol validation rules, the WAF can prevent protocol exploits including buffer overflow, malicious encoding, HTTP smuggling, and illegal server operations. Imperva provides a default policy that enables strict adherence to RFC standards, while allowing minor variations for specific applications.
Imperva WAF is a key component of a comprehensive Web Application and API Protection (WAAP) stack that secures from edge to database, so the traffic you receive is only the traffic you want. With the best website protection in the industry, Imperva provides PCI-compliant, automated security that integrates analytics that go beyond OWASP Top 10 coverage, and reduces the risks created by third-party code.
