API Endpoints Manipulation for Fun & Profit

Year from now, I was testing on a new domain of a target that I usually work on when I do bug hunting, And as a person who loves logic and reasoning I just love to go wild and try to understand how the application’s functions behave and what different parameters do , So my main interest is Business Logic and Broken Access Controls.

First Use-Case

So while going though Burp history to see various Requests, I came into this Request to get some information about the users in my Organization

GET /auth/api/v2/users HTTP/2
Host: api.redacted.com
User-Agent: 
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
X-Csrf-Token: [CSRF_TOKEN]
Authorization: Bearer [JWT_TOKEN]
X-Organization-Unit: [ORGANIZATION_ID]
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Te: trailers

And yes, As you might’ve guessed , why not changing the
X-Organization-Unit Header to other Organization id, And yes this exactly what really happened and the header was affected by a nice, simple and intuitive IDOR, I reported it and fortunately it wasn’t duplicate and I got a $$$ bounty.

But of course, I didn’t write a blog post for such a naïve IDOR so after some days of reporting it, I just thought of why not playing with the API endpoint to see if I can get other resources other than users in the Organization Tenant but in vain , And TBH that was weird to me as such a case was reasonably supposed to work because from my POV it’s more intuitive to apply a security validation over the HTTP Header to mitigate Access Controls Attacks other than handling it over different API Endpoints.

But anyways, I then moved to the upper layer and I just tried to change the API version from v2 to other versions and to my surprise it worked when I changed it to v1, Actually it was surprise to me as it was the first time I see a theoretical attack in action, So I reported it and it was accepted.

Second Use-Case

So after that I thought why not just manipulating and guessing some API endpoints afterwards , So I tried such a technique on multiple other domains on different targets but I wasn’t lucky , And then after few weeks I was hunting on another target that was using API heavily to retrieve Information for different resources , The request to get information about a user in a specific Tenant had specific structure form like this one

POST /api/GetUsersById HTTP/2
Host: api.redacted.com
Cookie:  
User-Agent: 
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
X-Csrf-Token: 
X-Requested-With: XMLHttpRequest
Content-Length: 
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers

{Some JSON Post Data To Specify IDs for users}

So it had that form like GetUsersById, GetListsById, GetLists and vice verse, So for sure always remember to manipulate the parameters and check for a juicy response, So yeah some endpoints were affected and others not, And then I remember that technique of manipulating the API Endpoint itself, so after guessing, I came into this Endpoint GetAllUsers which seems intuitive to try first but it took me some time to realize it, and I could retrieve Information about some internal users of the Company Staff itself

Further Notes

Read About API Fuzzing for Endpoint Automation

Conclusions

In the next time you are testing a web API for bugs, Don’t just tamper with parameters but put in mind to manipulate with the API endpoints as well

Have a great day ahead, and Happy Hunting