An attacker overrides or adds the 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.
The typical client-side scenario consists of persuading a victim to visit a malicious URL or XSS that exploits the HPP vulnerability.
For example, consider a web application that allows users to cast their vote on a number of different elections. The application, written in JSP, receives a single parameter, called poll id that uniquely identiﬁes the election the user is participating in. Based on the value of the parameter, the application generates a page that includes one link for each candidate. For example, the following snippet shows an election page with two candidates where the user could cast her vote by clicking on the desired link:
Suppose that Mallory, a Mrs. Green supporter, is interested in subverting the result of the online election. By analyzing the webpage, he realizes that the application does not properly sanitize the poll id parameter. Hence,
Mallory can use the HPP vulnerability to inject another parameter of his choice. He then creates and sends to Alice the following malicious Url:
Note how Mallory “polluted” the poll id parameter by injecting into it the candidate=green pair.
By clicking on the link, Alice is redirected to the original election website where she can cast her vote for the election.
However, since the poll id parameter is URL-decoded and used by the application to construct the links, when Alice visits the page, the malicious candidate value is injected into the URL.
No matter which link Alice clicks on, the application (in this case the vote.jsp script) will receive two candidate parameters. Furthermore, the ﬁrst parameter will always be set to green.
From the above scenario, it is likely that the developer of the voting application expected to receive only one candidate name, and, therefore, relied on the provided basic Java functionality to retrieve a single parameter. As a consequence, as shown in Table 1, only the ﬁrst value (i.e., green) is returned to the program, and the second value (i.e., the one carrying the Alice’s actual vote) is discarded.
In summary, since the voting application is vulnerable to HPP, it is possible for an attacker to forge a malicious link that, once visited, tampers with the content of the page, and returns only links that force a vote for Mrs. Green.
How different Web Applications Respond
The following examples show how the web technology of a web application is triggering or parsing same parameters in one query. The first example on how parameters are triggered can be shown below using Google search engine. In Google you can have the following query:
As shown in the above screenshot, the same parameter ‘q’ is being used three times. In this case, Google concatenates the three values with a space in-between, thus the end result will be ‘web application security’.
A second example is with the search engine Yahoo!. The following query has been used:
Having the same three parameters as with the previous example, it is shown that Yahoo! is only parsing the last parameter, thus the end result will be ‘security’.
This shows clearly how each technology is differently parsing the value parameters. The way each technology is parsing the parameters is not wrong, as long as the developer is aware of it. If the developer is not aware of this behavior or parameter triggering, then this can be dangerous for the web application. In addition, web technologies/languages have several secure functions that allow them to protect themselves by being able to control and manipulate these kinds of input parameters.
The below table you can find how other Frameworks react when receiving the same parameter multiple times. Like ASP.NET, if it receives two parameters, it will concatenate them, and therefore you can split the attack into those fields to bypass the WAF, which is out of scope of this blog.
Solutions and Mitigations
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 occurences of a parameter in a Query String