[Case Study] Bypassing IDOR via Parameter Pollution
While working on a pentest engagement, I found an interesting IDOR (Insecure Direct Object Reference) bypass using parameter pollution (a much overlooked test case). I was looking out for the IDOR vulnerabilities within the REST-API of the target application. Unfortunately, none of the endpoints were found to be vulnerable to the traditional IDOR. Only until I found that traditional IDOR’s can be bypassed by supplying same parameter name multiple times but with different values.
Here’s an example of how IDOR can be bypassed using parameter pollution.
Suppose, your account’s UserID is 123. To check for the IDOR, you would change the UserID value from 123 to UserID of another user (456). You may get “401 Unauthorized” status if the application is not vulnerable to traditional IDOR.
To bypass this using parameter pollution, pass two UserID parameters; one containing the Victim’s UserID and the other one includes your account’s UserID.
On the pentest engagement, I encountered the same scenario. It was the REST-API endpoint, where the application behaved in the following way:
a) Checked the first UserID parameter
b) The user (who is making request) should have his/her userID in the GET request.
Thus i was able to bypass both the points by adding 2 UserID parameters, where the first UserID is the victim’s UserID followed by attacker’s userID. Thus, tricking the application into thinking that i am sending a genuine request.
To begin with my testing, I proxied my mobile traffic to burp in order to intercept the REST-API endpoints.
My profile displays a full name and much of the information which is not displayed to another user. The request contains my UserID, noticing that, i did what most of the pentesters would do, that is changing the UserID to that of another user.
Unfortunately…..Nothing happened! I got a 401 Unauthorized error :(
Thinking of the parameter pollution technique, I tried adding my UserId parameter along with the victim’s id in the request to test in case if i am able to access the victim’s profile.
And yeahh! It worked :)
I got the full name of the victim and also much of the information which were not public. Not only this, It was possible to compromise each and every functionality of the app since all the parameters across the application were vulnerable to this.
