Opening up with day two and gathering some sources from Real-World Bug Hunting, we are going to talk about HTTP Parameter Pollution in different scenarios and its uses.
HTTP Parameter Pollution (HPP)
To start, HTTP is the process on how a website treats the parameters, and how an attacker can manipulate the parameters in a HTTP request. The attacker injects extra parameters into a request and the target website trust the parameters that the attacker has injected. This bugs can happen in the server side or on the client side where the client side would be the the browser. This attack will strongly depend on the parameter values, in order to obtain a successful attack, there most be some kind of experimentation with the parameters.
Server Side HPP in a simple way explained would be that the attacker send unexpected information, then the server-side code return unexpected results. With Server-Sides, not always the website will return a webpage, sometimes it will return some code based on information they receive from the URL is sent.
Let’s say there are three parameters from a bank where the user wants to transfer money between accounts. The parameters are
from, to, amount. You are planning to transfer money from account 12345 to 6790 an amount of $5000. This will result the following URL.
The attacker adds an extra parameter which would be
from=abcdef therefore, the site will validate both parameters, but it will withdraw the money from
abcdef account. This will result to the following URL.
In this case the the attacker would achieve a withdrawal of the money from account
abcdef which means that he will be withdrawing money from an account that does not belong to the attacker.
When a server receives multiple parameters with the same name, it can respond in a variety of ways. It depends on what kind of server the website is using. Luca Carettoni and Stefano di Paola explain this issue in a clear way in these slides, please go to slide 9. The picture from down below explains how the server validates and use the occurrences submited in the HTTP requests.
In some cases, the parameters that will perform actions in the HTTP request can be hidden due to the code in the server side which is not visible for the attacker. In this example, the attacker has the following URL.
Notice how the parameter
from is hidden in this case. Therefore experimentation comes to place an important role. There is not a from parameter in the the URL, but the attacker can insert the parameter at the end of the URL.
This kind of attacks allow the attacker to inject extra parameters in the URL to create effects on a user’s end. This refers a way that actions happen in the computer, often via browser, and not on the site’s server.
The following url will allow the attacker or victim to edit a site according the parameter
par can be described as one parameter due to the url encode value
%26 which would be translated as
&. The action that is requesting is edit after
%26 . An attacker can inject a value which can be encoded in the URL.
Write Ups and Explanations
So, the attacker used the following URL when the websites were about to be shared.
Then, the attacker change the URL to:
Therefore if the victim wants to post on Facebook, it will result to the following URL.
- One way to find HPP vulnerabilities is to look for links that appear to contact other services.
- Look for vulnerability opportunities when websites accept content and it appears to contact other websites.
The attacker tried to unsubscribe from the email. Once the attacker unsubscribe from the email clicking the unsubscribe bottom, the attacker will result with the following URL.
Then the attacker tries to add the following parameter in the url which is another uid from other user.
Then, he could unsubscribe the victim from the service.
In the follow option there is the following website where the attacker successfully injected the following parameter
screen_name. This allows to follow another user.
Once again, it follows the same methodology of parameter tampering, in this case the attacker set the following parameter to make to follow other user. The attacker tried this while injecting a parameter to submit a like to an user with this url
https://twitter.com/intent/like?tweet_id=661625230297821184&screen_name=ericrtest3 . This will result the following URL.
More techniques and filters with Shodan
From Rajesh Ranjan who’s curious about the usage of shodan. He was wondering how he could extract different kind of assets with other Shodan filters, this time using SSL certificates in order to look for assets from the target. Rajesh Ranjan used PayPal because is a public program in the Bug Bounty platform HackerOne. For finding assets in Shodan use the following filter:
This will display the results having a
There is a chance to apply another filter which will show assets hosted on AWS.
Here there is a write up where a researcher was able to find XSS with this technique. The write up is called “How I Found XSS By Searching In Shodan”