Broken Access Control (BAC): Advanced IDOR exploitation

Today's estimated reading time is: 11,5 min

Last week we went over various different IDOR cases and how you can exploit each one of them.In this week's issue, we are going to look at more advanced (and harder-to-spot) IDOR vulnerabilities.

Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that finds vulnerabilities before you do.Waitlist is open, join today ===> https://novasec.io/

Advanced IDOR exploitation:

"Object-based" IDOR:

Most APIs that you'll come across nowadays are REST APIsThese kinds of APIs often accept data in the form of a JSON object and sometimes developers mess up with handling this dataAnd you can use this to your advantageLet's go through some examples belowYou surely have seen this kind of request before:

In the above request, we tried to update the data of our second test account (using our first test account)And as you can see, it of course returned a 401 UnauthorizedNow it is possible for us to wrap the user ID in an array and with that supply multiple IDs:

Now, depending on how to backend might handle it, it can update the data for both users just like in this caseYou can also map it into another JSON object (example of the POST body):

Or use a boolean (be careful with this):

You can try various other things such as:

• replacing the user ID with a very large digit: 123500000

• adding zeros in front of the user ID: 000001235

• replacing the user ID with a negative digit: -1 or -1235

• replacing the user ID with a decimal number: 1235.0

• passing multiple user IDs as a string value separated by a comma: "1234,1235"

• replacing the user ID with a wildcard or a percentage sign (again, be careful with this if you're testing it on features that update/delete data): "*" or "%"

These are just a few examples and I recommend trying all of these outAnd depending on your target, it can result in an IDOR vulnerability

Multi-step IDOR:

These types of IDORs can often easily be exploited as they are sort of "hidden" behind the first pageBasically, the vulnerable API endpoint is used AFTER you complete a step or a series of stepsFor example, say you got a target that has a feature that allows you to send in your details and apply for job offers:1) You fill in the first form and click next (data gets saved in the background as a draft application, but no IDOR on the auto-save endpoint)2) You submit your application (data gets saved another time, no IDOR on this new endpoint)3) In the last step, you get to review your details before submitting the final application (data gets saved but no authorization checks are set in place >>> IDOR on this last endpoint)From the example above, we had to go through a series of steps that all looked secure but the last step (reviewing and submitting final changes) did not properly check for any authorizationThese are multi-step IDORs and can easily be exploited if you understand the target you're testing well enough

Second-Order IDOR:

Second-Order IDORs are IDOR vulnerabilities but the only difference here is that the web app uses your input to indirectly reference an object or resource.Your ID gets stored first, and then used later to reference a data resource.There are a lot of different cases like these but I will only go over 1 case in this article (check the additional resources section for another case of this type)I found this special case a while ago where an API reflected my input without any validation in the path of an internal-only API request It allowed me to make HTTP requests on behalf of the backend API (SSRF) and unfortunately, there was nothing that I could chain this with except the IDORLet's first understand how this case of IDOR can arise as it will help you understand how you can identify these easily as wellMost companies today tend to separate their web project into components (or layers, it's called a "multi-tier" or an "n-tier architecture")And the thing here is, when user data is passed without any type of validation to another layer (or service), it may introduce weird (and exploitable) behaviour, just like in this caseNow one thing to mention is that I found this on 1 single API endpoint, the other endpoints seemed to URL encode my input first before forwarding it to the internal API (I recommend checking for all API endpoints)Let's take a look at a simple diagram:

When I requested my profile data, a POST request was sent to the APINext, the request got forwarded to the internal API, and afterwards, the internal API retrieved my info from the database and returned it backAnd as you might have noticed, the user ID got reflected in the path but without any validationThis gives us 2 options:

• We could either inject a new line feed character and request any other resource on behalf of the internal API

• Or we could traverse paths and retrieve another user's ID

At first, I tried exploiting the SSRF vulnerability:

And now you may ask how I came up with thisI simply tried injecting a path and it returned a 404 (you could also try passing a hash fragment, a query parameter and/or URL encode your input):

The second option is traversing paths like below:

And depending on the target, it can be vulnerable if there are no authorization checks put in place on the internal APIThis is most likely when the API does not forward the authorization header for exampleThis is just one case of a second-order IDOR why my user input was used in a second query without any validation

"ID-less" IDOR:

ID-less IDORs are just like any other IDOR vulnerabilities however, they are a bit harder to spot.Let me explainSay you have a target that you're testing out and looking at the intercepted requests, you keep seeing that all your profile data gets retrieved from the following API endpoint (this is just an example, there are many other variations):

If you haven't noticed yet, the "current" keyword is a reference to your accountBut in the response, we can also see that there's a customer ID in thereAnd you may have already guessed it, sometimes replacing the "current" keyword with your ID will return the same response:

And if it did (in your case), then it may be vulnerable to IDORNow let's be real, chances to find an IDOR on such a critical endpoint are very slimThat's why you should look furtherSo here's what I did:I found the exact same case a while ago, I replaced the current keyword with my ID (that I retrieved from my response) and got the same response (if you receive a 404 Not Found status, know that the ID is ineffective on that endpoint and try other identifiers such as your email)So I went ahead and changed the ID to my second account's ID and as you might've guessed, I faced a 401 UnauthorizedBut instead of stopping there, you should try the same technique on other API endpointsI did just like that and found that I was able to remove 2FA from my second account

Additional Resources:

• Another example of a second-order IDOR vulnerability by Ozgur Alp

• A deep dive into Broken Access Control Vulnerabilities by Inon Shkedy

• An IDOR Lab by Portswigger to test for IDORs

• A Twitter search query for IDOR bugbountytips (writeup links often get shared on Twitter, recommend taking a look there for any resource you need)

Thank you for reading this far!

I hope you've enjoyed & learned something new from this post!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server:

• Help you save time & earn more bounties using Nova Security: