What is HTTP Parameter Pollution and How To Prevent It. In this post, we will show you how to fix client-side http parameter pollution (reflected). After reading this article, you will learn how to prevent and Fix HTTP Parameter Pollution in Web Server, PHP, JAVA.
Threat actors can mask scripts and processes inside URLs with HTTP Parameter Contamination (HPP) attacks. These threats was first discovered in 1999. This technique can also cause the parameters in the URL and the request body to be polluted by threatening actors.
Therefore, this may lead to improvements in the app’s actions, such as cross-site scripting, changes to rights or allowing unauthorised access. For today, HTTP Parameter Pollution (HPP) remains a concern to look out for. To find out how HPP attacks operate and how to detect them, read on.
Tags: HTTP Parameter Pollution | Advanced Threat Protection | HTTP | Threat Protection
Trending Security Articles
- DNS Spoofing- How To Prevent DNS Cache Poisoning
- Policy & Cloud Security Compliance Standards.
- How to Avoid DNS and DNS Spoofing Poisoning
- 9 Potential Threats hindering the Promotion of Cloud Computing Industry
- Cloud Computing and Enterprise Computing faces the same Security Threats
The Impact of HTTP Parameter Pollution
To execute several different unwelcome actions, an attacker may use an HPP attack. The original hardcoded HTTP parameters can be overridden, the application behaviour and access changed and the user-uncontrollable variables manipulated.
HPP attacks also allow individuals to circumvent validation checks of inputs and rules for the web application firewall (WAF). It opens up attack paths, including cross-site scripting (XSS), injection of structured query language (SQL). By inserting several parameters of the same name keeping different values and held apart by delimiters, HPP attacks can be carried out by polluting HTTP GET/POST requests.
Types of HTTP Parameter Pollution
It is possible to distinguish HPP into two kinds: client side or server side. When several parameters of the same name are obtained, various web servers function in different ways, because ways of parsing parameters vary. Depending on the way requests are managed, client-side or server-side HPP attacks are likely.
For instance, the last occurrence of a parameter is used by PHP/Apache-based apps, while the first is used by Jakarta Server Pages (JSP)/Tomcat-based apps. The table below illustrates how this is done by multiple languages and web servers.
| Technology/HTTP back-end | Overall Parsing Result | Example |
| ASP.NET/IIS | All occurrences of the specific parameter | par=val1,val2 |
| ASP/IIS | All occurrences of the specific parameter | par=val1,val2 |
| PHP/Apache | Last occurrence | par=val2 |
| PHP/Zeus | Last occurrence | par=val2 |
| JSP, Servlet/Apache Tomcat | First occurrence | par=val1 |
| JSP, Servlet/Oracle Application Server | First occurrence | par=val1 |
| JSP, Servlet/Jetty | First occurrence | par=val1 |
| IBM Lotus Domino | Last occurrence | par=val2 |
| IBM HTTP Server | First occurrence | par=val1 |
| mod_perl,libapreq2/Apache | First occurrence | par=val1 |
| Perl CGI/Apache | First occurrence | par=val1 |
| mod_wsgi (Python)/Apache | First occurrence | par=val1 |
| Python/Zope | All occurrences in list (array) | par=[‘val1′,’val2’] |
Source: https://en.wikipedia.org/wiki/HTTP_parameter_pollution
Client-Side HPP
A HTTP Parameter Contamination attack on the client side is linked to the client or user environment, meaning that the actions of the user are influenced and without their knowledge will cause a malicious or unwanted action.
When an app embeds user feedback in URLs in an insecure way, this danger occurs. This opening can be used by an attacker to create a URL that can change URLs within the answer if accessed by another person, by adding more query-string parameters that overwrite current ones.
This which result in associations and forms acting in ways that were not intended to be used. For example, using HPP, it might be possible to alter an invitation type such that the invitation is sent to another user.
Depending mostly on what the affected software will do, this may have a greater or lesser effect. And for an app that has little clear effect of its own, to make the ultimate attack worse, an attacker may use it in combination with other openings.
Example: A Movie Rating Site
Let’s examine a client-side HPP attack in a real-world example.
You can consider a website for movie reviews. People will send a movie ‘likes’ or ‘dislikes’. Two links (Link A and Link B) containing two parameters,’ mname’ and ‘mrating’ are included in this sample website. Mname holds the name of the movie for which the ranking is given, and ‘mrating’ holds for every given movie the importance of either likes or dislikes.
URL: http://host/movie.jsp?mname=littlestarLink A: <a href=”rate.jsp?mname=littlestar&mrating=like“>Likes for LittleStar movie</a>Link B: <a href=”rate.jsp?mname=littlestar&mrating=dislike“>Dislikes for LittleStar movie</a>Let’s say for the film “LittleStar” the publicity team needs more likes. Thus, the attacker/intruder generates and shares the cause URL with the victims using HTTP Parameter Pollution:
http://host/movie.jsp?mname=littlestar&mrating=likeThe infected parameter ‘mrating’ was inserted with a value of ‘like’ by an attacker and/or intruder. They are diverted to the portal featuring two injected links when the victims click on the doctoral page (Link A1 and B1 for the film ‘LittleStar’).
Link A1: <a href=”rate.jsp?mname=littlestar&mrating=like&mrating=like”>Likes for LittleStar movie</a>
Link B1: <a href=”rate.jsp?mname=littlestar&mrating=like&mrating=dislike”>Dislikes for LittleStar movie</a>
Furthermore, the honest requests Link A and B have been contaminated by adding another boundary (mrating) with the particular payloads. For this situation, Link A1 and Link B1 become malignant href joins.
Since the application is planned on JSP in the two connections A1 and B1, the principal event of the comparative boundaries (the infused boundary) will be gotten back to the application and the subsequent will be overlooked.
Regardless of which connects the casualty taps on, the application will devour the mrating=like boundary in both href joins, in this way delivering more prefers to the film “LittleStar.”
Server-Side Attacks
Thus, the attacker’s purpose in a client-side attack is to attack other users. The intruder may use an at-risk web app in several ways in the server-side version. They may access protected data or execute activities on the server side that are either not allowed or not expected to be run.
It is possible to execute server-side attacks by inserting a similar parameter into existing values or by using parameters which are not accessible to the end user.
Check out these related posts.
- 9 Best WiFi Penetration Testing Tools Hackers Use in 2021
- Security Strategy Planning Guide to Prevent DNS Attacks
- 2021 Top Rated Unified Security Management Software
- Beware: E-Commerce Skimming is the New POS Malware
Example: Robbing a Bank
In order to see how the HTTP Parameter Contamination attack could happen on the server side, let’s analyse a classic example of a bank transaction.
In the example, Bob is transferring $10 to Alice by entering a dollar amount and choosing the transfer account.
In this case, by entering a dollar sum and selecting the transfer account, Bob transfers $10 to Alice.
The request for the transaction will be as shown below:
POST /transfer.php HTTP/1.1
Host: bank.com
—
Connection: close
amount=10&payee=Alice
In a request submitted to the server, there are two parameters: the sum to be transmitted and the payee. Another request is sent from the server to the back-end payment portal after the request reaches the server. It is where the real exchange happens. Now, the payment gateway’s submission looks something like this:
http://paygate:8080/?payer=Bob&payee=Alice&amount=10
Next Step: Add a Parameter
This request is identical to the previous one, except an additional parameter is available: the payer. In the initial request from the app, the ‘payer’ parameter is not present, so the attacker could easily change it and move all the money from either account. The server uses the payer’s cookie to retrieve the name to discourage this, and applies it to the back-end request to avoid modifying the meaning.
It is not necessary to adjust the payer benefit. However, in order to inject a related parameter with a different meaning, we can also use HTTP Parameter Pollution. In this case, in PHP running on Apache, the payment gateway is written. So, at the end of the current parameters, an attacker will add two additional parameters.
We also know that only the last occurrence of the parameters is considered by PHP/Apache, and the first occurrence is overlooked.
The payment gateway will see this:
payer=Alice&payee=Bob&amount=1000
POST /transfer.php HTTP/1.1 200 OK
Host: bank.com Transaction Successful
—
Connection: close
amount=10&payee=Alice&payer=Alice&payee=Bob
The money will be debited from Alice’s account after the payment conversion completes, and credited to Bob’s account. Thus, through this assault, Bob could steal all of Alice’s assets.
Does Firewalls for Web apps make a difference?
Now the question is; does Web Application Firewalls Make a Difference? The above attack is a form of direct-server attack where no app firewall, such as a mobile application firewall (WAF), is mounted. When app firewalls are in place for security, they can also be bypassed by attackers.
Some WAFs can check and validate only a single occurrence of a parameter, depending on the method used, either the first or the last one. This attack is based on how the parameters of the same names are parsed by the server.
WAF HTTP Parameter pollution may have a few different situations. Then, the laws on emissions may be bypassed. This may be achieved because the last occurrence of the parameters is taken by the server and the WAF rule is configured to only validate the first occurrence, or vice versa. Or, it might occur when two of the same parameters with different values are joined by the server and the WAF rule is programmed to validate them one by one.
How Does HPP Bypasses Firewall Rules?
Taking the scenario that follows. In order to execute cross-site scripting, an HTTP Parameter Pollution attack can be used here to override WAF rules.
Find the following URL in order to bypass the firewall rule:
http://myapp/vul.cgi? Par=valAn attacker should add an extra parameter at the end of the URL with the same name but with a different meaning for HPP to be successful in the above URL/app. This will make the request look like this:
http://myapp/vul.cgi? Par=val1&par=val2 Par=val2In this situation, because firewall rules are enforced, there is no improvement in what the app does. However, by incorporating an XSS/SQL payload so that the attack could still be carried out, this law can be bypassed.
The malicious XSS/SQL payload could be broken into two pieces by an attacker and two separate values could be injected into the same parameters.
http://myapp/vul.cgi?par=”> <img src=a onerror =al&par=ert(1)>After bypassing the firewall, the above XSS payload ” “><img src=a onerror=alert(1)> is acknowledged and executed by the server.
How to Prevent HTTP Parameter Pollution
If you want to prevent or even fix HTTP Parameter Pollution, you have to be smart. There are many ways of safeguarding against HPP. Making sure that an extensive and sufficient validation of feedback is carried out. Any data generated by the user that is expressed in the HTML source code of the HTTP response should be encoded according to the context in which it is reflected. Beware of several instances of parameters identical to these. Finally, use only safe means of accessing network technologies and languages with common sense.
You should also remember certain other safety advice while using a WAF. For the WAF to not accept multiple instances of the same parameter in a single HTTP request, the simplest approach would be. This will discourage all sorts of threats from taking place. Now, in all instances, though, this may not be feasible, since certain applications might require multiple redundant parameters. In the same request, they may be configured to send and accept several HTTP parameters of the same name.
In summary, the WAF could also view the HTTP request in the same way the client does, to secure these types of applications. Furthermore, be mindful of the vulnerabilities of particular components of the software and use strict filtering. Lastly, it will allow you to identify HTTP Parameter Pollution until it hurts if you stay alert to these openings. Source.
Topics related to HTTP Parameter Pollution and How To Prevent It
- 1. how to fix http parameter pollution
- 2. what is http parameter pollution
- 3. http parameter pollution hackerone
- 4. how to prevent http parameter pollution in php
- 5. how to prevent http parameter pollution java
- 6. how to fix client-side http parameter pollution (reflected)
- 7. http parameter pollution remediation
- 8. http parameter pollution portswigger
Recommended Articles to help Fix HTTP Parameter Pollution
- Working Safely from Home – Online Security Measures in this Pandemic
- Importance of Web App Security over the Increasing Web Application Attacks
- Hybrid Cloud Security Puzzle: Integrated Solutions for Cloud Computing
- Make Sure Your Security Policies Survive the Transition to the Cloud
- Best Methods to Improve Information Security in Companies
- Healthy Ways to Guarantee Public Cloud Security: Best Practices & Guidelines
