HPP
HTTP Parameter Pollution
The HPP attack is one where we are looking to abuse the parameters used within a URL. By changing the order, setting the same parameter more than once, adding in extra param-keys if not expected but still interpreted, or modifying parameter values to exploit deserialization vulns. The most common of these will be the overwrite of the parameter by including it twice. Ex: '?rate=5&rate=9999'
Things to look for:
This one is a bit more trial and error to test. The technologies used on the site make a big difference on how to deploy an attack. The following describes which param in HPP gets the significance.
Apache: last occurrence
PHP: last occurrence
Tomcat: first occurrence
IIS: all occurrences
ASP: all occurrences
Some other starting spots to look for HPP could be:
HTTP redirects from URL params (for an HPP Open Redirect)
Other forms of cross site contacts from URL params
Params that hold user IDs
Cross-Site Content creation/shares
Examples:
Param Overwrite (Server-Side):
Here we have a site that uses the below URL to rate restaurants. The site then has server-side code that averages the star ratings (1-5 stars) and displays that on the restaurants home page. With HPP we can leave an extra high review to bump up the overall rating.
http://some.site/rate?restaurant=mikkies&rate=5&rate=9999
For this to work the site would need to be using a server side technology like Apache or PHP and then only be checking the first occurrence of "rate" to be between 1-5 and then be overwritten with 9999 afterwards, bypassing the check.
Param Overwrite (Server-Side vuln, Client-Side impact):
Here we are utilizing HPP to redirect off of a facebook to a site that is not listed in the sites acceptable domains list. We can send a link like this to a victim who will be redirected off of facebook to our site and will not be prompted with a notification if the developer forgot safe coding practices for HPP.
facebook.com/sharer.php?u=hackerone.com/blog/into-signal?&u=evil.com
White-Boxing:
Extra Param:
The following code is would be vulnerable to HPP because of line 3 where the developer used an append << , concatenations like this are dangerous and not just for HPP.
user.id = mikejones
def prepare_transfer(params)
params << user.id
transfer_money(params)
end
def transfer_money(params)
to = params[0]
amount = params[1]
from = params[2]
process(to,account,from)
end
Because the params injected by the script are in a array [] and the user.id is appended we can change what lays in each index of the array with HPP. So although its expecting something like the first set below we can also add the user we want to try to transfer from. So rather than passing in [our2ndAccount,9999] we can pass in [our2ndAccount,9999,victimAccount] which will end up using the victims rather than our mikejones account when reading in params [2]
Expected: ?to=our2ndAccount&amount=9999
HPP: ?to=our2ndAccount&amount=9999&from=victimAccount
Deserialization HPP:
From the owasp pdf below, there is a theoretical example of this type of HPP. The below code sample shows how we can pollute par to allow us to edit a page.
Server code: <? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?>
URL: ?par=123%26action=edit
The above server code will take par and decode any special characters like %26 which will then become & . We have now snuck in another parameter and depending on how this is then used we may be able to leverage an HPP attack.
For further reading on HPP:
Last updated