Broken Access Control (BAC): IDOR exploitation

Today's estimated reading time is: 13 min

Last week we saw a brief introduction to broken access control issues, what they are in general and where they often are present in web applications.Today we are going to dive deeper into IDORs. IDORs are easy to spot but most people aren't finding them because they aren't looking where they should be.That's why I made these posts. By the end of these, you will be able to find way more IDORs. I highly recommend also reading all the articles I attached in the additional resources section.

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/

Insecure Direct Object Reference:

IDOR vulnerabilities arise when the web app you're testing accepts & uses user input to get back or update a data entry without validating if that supplied ID is in fact yours.As a new bug bounty hunter, you'll notice that despite all the claims that this vulnerability type is easy to spot, you still can't find an IDOR vulnerability.And that's okay, to find more IDORs you should spend more time on targets that have a large code-base + should focus on newly introduced features or forgotten/less-accessible features. As these will often contain such vulnerabilities (they usually haven't been tested before).For example:• Instead, of looking for IDORs on your profile (a heavily tested functionality), look for them under your backup settings (a less exposed place).• Instead of focusing on the main feature (posting an image), look at the options it has (editing posts or images).• Instead of focussing on editing the post, look at the auto-backup feature.• Instead of testing a feature that has been tested over and over again, test that newly implemented 2FA security feature.See a trend here now? GoodNow that we've clarified where to look for IDORs, let's start with looking at some basic IDOR examples and in the next post look at some more advanced and harder-to-spot cases (this will be sent next week)!

Basic IDOR:

Basic IDOR vulnerabilities are where we can easily change a predictable identifier (ID) such as a numeric int value with another ID.Let's take a look at a small example. Our current account has the user ID of "1234".Making the following request should allow us to return the data of another user, in this case, our second test account.

It's sometimes just as easy as that, but it can get trickier.Let's go through some more cases.

UUID-based IDOR:

More and more web apps start to enforce the use of UUIDs because they aren't predictable and can not be brute-forced in any way.If you are unfamiliar with what a UUID is, no issue below is an example of one:

However, this shouldn't be seen as the only measure against IDOR vulnerabilities. As many times, these UUIDs can be retrieved or returned back in the response in another way (or form).Say we got the following API endpoint: /api/users/{UUID}

Making a GET request to that endpoint returns all data associated with that user. However, upon taking a closer look at the response returned back, we can see a second user ID. One that is predictable.What we could do now to exploit this IDOR is 1) try replacing the UUID with the numeric ID and 2) find the UUID referenced elsewhere in the web application.The first option is easy, we simply send the following GET-based request and check whether the same information is returned, and apparently, it is:

The second option involves us looking for our UUID in the responses. One way to do so is by using our proxy interceptor and searching for our UUID and afterwards looking for other users' UUIDs at the same place.Another way is to just simply to check common places where that UUID may get leaked. For example, public profiles, built-in messaging features (they have to identify the receiver in one way, right?), profile pictures, etc.You could also look for these on public sources such as the Wayback Machine (archive of the internet) or search engines such as Google, Bing, etc.Don't worry if you are unfamiliar with using public sources, here's an example.Say we are looking for more UUIDs, all we got to do in this case is use search filters and search on Google and Bing: "site:api.example.com inurl:/api/user"You could also search the internet archive for any archived UUIDs. Simply visit archive.org/web and submit the URL, afterwards look at the saved URLs as that is where you would want to look.

Method-based IDOR:

Before I tell you how to test for this type of IDOR, let's first take a look at a small code snippet. It'll help you understand why and where these types of misconfigurations often arise.

As you can see in the above image, 1 route is defined: /api/messages/{ID}However, it accepts 2 HTTP methods, one function accepts the POST method, and the other one the DELETE method (both functions are able to delete the message).And as you might have noticed, the POST method does enforce the authentication & authorization checks. Meanwhile, the DELETE method does not.This is often the case when new API endpoints are added. Developers forget about implementing the right authentication & authorization checks and it doesn't get caught until you find & report it.Getting back to the example. Sending a POST request, like below, to delete another message ID (that isn't yours, like "1235") will return a 401 Unauthorized.Meanwhile sending a DELETE request to the same endpoint, will delete the other message and return 200 OK.

I also recommend trying and changing the content type of your request body as sometimes, the same can happen here as well.

IDOR through outdated API Version:

This is also applicable to different API versions. For example, say the /api/v2/message endpoint did not allow you to delete the message using the DELETE method.Trying an older API version such as /api/v1/message might allow you to do so easily:

This is often the case when a new version of an endpoint gets introduced, but the older one is still accessible.

IDOR through parameter pollution:

Parameter pollution is basically supplying the same parameter name multiple times in a request (each with a different value).And depending on the service that is running and accepting/parsing the parameters, it may concatenate the values, only read the first value or only read the last one.This behaviour can be used to evade certain filters to still retrieve other users' data. That is why it is important to also test for parameter pollution when testing for IDOR vulnerabilities.

IDORs in GraphQL:

As in other services, GraphQL can also be misconfigured and contain IDOR vulnerabilities (and much more).Exploitation however is sometimes much harder as you need to identify the queries and mutations (sort of like methods/functions to identify what action to conduct) available + craft a valid request.Sometimes, the Introspection Query (you ask GraphQL to return all information about what queries it supports) is enabled, and with that, you should be able to list all available operations.If that is not the case, you could also make use of the built-in autocomplete feature. As with that, you'll also be able to enumerate more operation names just by supplying a few common keywords.However, if both features are disabled, I recommend going through the whole application and using each and every functionality available + reading javascript files as they also often contain operation names.With that, you should be able to enumerate all operation names and test each one of them without any issues. Sometimes it's just replacing an ID with another ID.

Additional Resources:

• Find more IDORs by @thaivd98 (some very interesting cases)

• A Notion DB to find more IDORs (you don't need Notion to view it)

• Find more IDORs by @vickieli7

• Tips and Tricks for finding more IDORs by AON.com

• Top 220 IDORs found by @_nyan (highly recommend going through all disclosed Hackerone reports)

• Top 25 IDOR reports (again, read all 35 disclosed reports, it will help you understand IDORs!)

• More info about HTTP Parameter Polution by OWASP (learn more about HPP vulnerabilities)

• An official introduction to GraphQL by GraphQL (recommended if you want to get really into GraphQL hacking)

• A detailed blog post all about exploiting GraphQL by @Yeswehack (has the introspection query)

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

Thank you for reading this far!

I hope you've enjoyed this post! In next week's issue, I will go through advanced IDOR exploitation techniques! Stay tuned!

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: