HTTP Parameter Pollution
The parameter enables pages to load data from the back-end e.g., ID, search query. They make websites more interactive to the back-end as well as make them easy to use for visitors. Multiple parameters can be added with the help of special chars like (&, +,;) to a single page, which makes the page dynamic and a single page can have multiple views. Pages accept only parameters defined by developers in code and they should be sanitized properly to avoid malicious activity.
HTTP Parameter Pollution is simply adding one extra parameter with a similar one used by the server. We can bypass the Web application firewall (WAF) checks that used for input validation checkpoints and Ruleset for blacklisting through parameter pollution. Behind the scenes, the front-end checks for validation on only one parameter, and another parameter get passed to the back end without checks.
Firstly, need to gather information about the backend and parsing method used by the application. Then need to find parameters that are taking input from the user and check how it behaves after parameter tempering. Parameter Pollution can be tested against GET request parameter, POST parameters, and in the Cookie header.
Different languages and frameworks handle these parameters differently, some consider the first parameter and some of them will go for the second parameter and some will combine the second parameter with the first parameter. For exploitation, an attacker needs to craft a payload according to the back end of the web application.
Here is a List of Some Back-end Server that Supports the First Occurrence only:
- JSP, Servlet/Apache Tomcat
- JSP, Servlet/Oracle Application Server
- JSP, Servlet/Jetty
- IBM HTTP Server
- mod_perl, libapreq2/Apache
- Perl CGI/Apache
- mod_wsgi (Python)/Apache
Back-end Server that Supports the Second Occurrence only:
- IBM Lotus Domino
Back-end Server that Supports All Occurrence:
Exploitation Scenario for Parameter Pollution:
In this section, we will be discussing the exploitation of Parameter Pollution in Business Logic flow. Here is an application that provides services for online food ordering.
- Request for ordering food to cart.
Fig. – Adding Item to Cart.
- Intercept Request in BurpSuite and Temper qty Parameter.
Fig. – Performing Parameter Pollution on qty parameter
- Negative Number of Dishes Gets Added to Cart
Fig. – Parameter Pollution exploited Successfully
Parameter Pollution is a test case, it is not vulnerability by itself, but it can be chained with another vulnerability. It can be used for URL rewriting, chaining behavior of the application. Parameter Pollution impact depends on context or web application functionality. Parameter Pollution affects server-side as well client-side components.
Signs That HTTP Parameter Pollution is Present in Web Application:
- HTTP parameters get override on adding an extra parameter
- The application behaves differently for adding an extra parameter
- Access and potentially exploit uncontrollable variables
- Application improperly validating extra parameter
Vulnerabilities Can be Found with HTTP Parameter Pollution:
- SQL Injection LDAP Injection, XML Injection, XPath Injection, Command Injection, XSS.
- IDOR through parameter pollution report ( https://0xgaurang.medium.com/case-study-bypassing-idor-via-parameter-pollution-78f7b3f9f59d )
- Account takeover through parameter pollution report ( https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be )
- Business Logic
Countermeasures For HTTP Parameter Pollution:
- Context Data validation
- Output encoding
- Filtering is the key to defend our systems
- Apply URL Encoding
- Use of strict regex in URL Rewriting
- 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
Attack & Pentest Team
Varutra Consulting Pvt. Ltd.