| Name |
HTTP Parameter Pollution (HPP) |
|
| Likelyhood of attack |
Typical severity |
| High |
Medium |
|
| Summary |
An adversary adds duplicate HTTP GET/POST parameters by injecting query string delimiters. Via HPP it may be possible to override existing hardcoded HTTP parameters, modify the application behaviors, access and, potentially exploit, uncontrollable variables, and bypass input validation checkpoints and WAF rules. |
| Prerequisites |
HTTP protocol is used with some GET/POST parameters passed |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Find User Input] The adversary finds anywhere in the web application that uses user-supplied input in a form or action. This can also be found by looking at parameters in the URL in the navigation bar of the browser |
|
| 2 |
Experiment |
[Add Duplicate Parameter Values] Once the adversary has identified what user input is used as HTTP parameters, they will add duplicates to each parameter one by one to observe the results. If the response from the HTTP request shows the duplicate parameter value concatenated with the original parameter value in some way, or simply just the duplicate parameter value, then HPP is possible. |
- In the URL, add a duplicate parameter by using the "&" delimiter. For example "par1=val1" becomes "par1=val1&par1=val2". Depending on the backend API, this could be treated as "par1=val1, val2", which could lead to par1 being set to val2, ignoring val1.
- If the request is created based on user input directly on the page, the adversary will test by adding an encoded delimiter to the input. For example, the adverary might supply "1000%26action=withdraw" and the backend might interpret a POST request with the paramters "action=deposit&amount=1000&action=withdraw"
|
| 3 |
Exploit |
[Leverage HPP] Once the adversary has identified how the backend handles duplicate parameters, they will leverage this by polluting the paramters in a way that benefits them. In some cases, hardcoded parameters will be disregarded by the backend. In others, the adversary can bypass a WAF that might only check a parameter before it has been concatenated by the backend, resulting in malicious queries getting through. |
|
|
| Solutions | Configuration: If using a Web Application Firewall (WAF), filters should be carefully configured to detect abnormal HTTP requests Design: Perform URL encoding Implementation: Use strict regular expressions in URL rewriting Implementation: Beware of multiple occurrences of a parameter in a Query String |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-88 |
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') |
| CWE-147 |
Improper Neutralization of Input Terminators |
| CWE-235 |
Improper Handling of Extra Parameters |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-15 |
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on. |
| CAPEC-676 |
An adversary targets software that constructs NoSQL statements based on user input or with parameters vulnerable to operator replacement in order to achieve a variety of technical impacts such as escalating privileges, bypassing authentication, and/or executing code. |
|
| Taxonomy: OWASP Attacks |
|
Entry ID
|
Entry Name
|
| Link |
Web Parameter Tampering |
|