The new year has begun, and as a penetration tester at Black Hills Information Security, one thing really struck me as I reflected on 2023: a concerningly large number of web applications suffered from insecure direct object reference (IDOR) vulnerabilities that were critical in severity because they exposed highly sensitive data. In the last four months of 2023 alone, I discovered five such instances. This issue is slipping through the cracks with alarming frequency, even in web applications that are otherwise fairly well-secured.

Those of you who are unfamiliar with IDOR should consider checking out Kelsey Bellew’s blog post from February 2016 HERE for a great high-level overview. I will also be covering the basics of IDOR here, as well as additional tips for preventing and detecting it.

In essence, IDOR is when an authenticated user of a web application is able to gain unauthorized access to resources by changing the value of an identifier in an HTTP request. There are a number of spots in the HTTP request where these identifiers may be, such as a URL query strings, HTTP POST parameters, or even in cookie values.

If the web application makes an HTTP POST request to retrieve the name, email address, and phone number of the current user with an ID of 10001 and changing the ID in the request to 10009 returns the name, email address, and phone number of an entirely unrelated user, then IDOR has been successfully exploited. This is a consequence of the application failing to check whether a user is authorized to access a particular set of information while carrying out a request.

Below is a step-by-step example of IDOR exploitation. First, the user, Sideshow Bob, accesses his own data through normal means at the URL, /user/10001.json.

The HTTP request that returned the above data is intercepted with Burp Suite and sent to the Burp Suite Intruder module. The number 1 in the URI /user/10001.json is specified as a payload position.

Next, the Burp Suite Intruder is configured to inject the numbers 0 through 9 into the payload position.

The resulting Burp Suite Intruder output returns not just Sideshow Bob’s data, but also Bart Simpson’s data at /user/10009.json, which Sideshow Bob was not intended to view.

The fact that IDOR, by definition, can only be performed post-authentication may give some developers a false sense of security regarding this issue. However, if the vulnerable web application has a registration page allowing anyone to make a new user account, the information is as good as public because anyone on the internet could make an account and access that data. Even if account registration is restricted, the potential for damage is so substantial that the risk from IDOR attacks should not be taken lightly.

Because unsecured identifiers may be used while the application carries out a variety of actions, the consequences of IDOR can be wide-ranging. Examples of IDOR attacks that I have successfully exploited over just the past few months include:

• IDOR affecting password change functionality, which made it possible to change the password of any user in the application.
• IDOR that allowed low-privilege users to perform admin functions, such as user impersonation, password changes, and modification or deletion of user accounts.
• IDOR that disclosed large amounts of personal information about every user in the system, including full names, mailing addresses, email addresses, phone numbers, and other sensitive data. This information can be very damaging to a company’s reputation if it winds up in a data dump on the dark web.

Preventing and addressing IDOR requires both developers and penetration testers to be proactive, with the steps I’ve outlined below.

Tips for Testers – Discovering IDOR

• Examine HTTP requests while you are exploring the application and test for IDOR using the Burp Suite Intruder as described earlier in this blog post. Care needs to be taken when performing these tests in production, but whenever possible, it is prudent to inject hundreds or thousands of numbers as payloads, as numeric identifiers are not always sequential, and a large number of guesses may be necessary to successfully identify IDOR.
• Know what information in the environment is considered sensitive. Sometimes it is obvious which data is sensitive, but sometimes it’s not. Work with the stakeholders to understand which data they are most concerned about.
• Once you have identified which data is most sensitive, identify which endpoints return this data and prioritize testing those, especially if there is a limit to how much time you can spend testing an application.
• Be extremely thorough. Even if access controls are enforced correctly in 99 out of 100 endpoints, that one unenforced endpoint can expose a lot of information.
• Whenever possible, perform testing with two user accounts per privilege level. If there are so many user account privilege levels that this would be impractical, aim to test with user accounts that have the least level of privilege and the highest level of privilege at a minimum.
• Be wary of false alarms. Authenticated users are often intended to access certain personally identifiable information in certain contexts. For example, an application accessible only to company employees may have a company directory with employees’ contact information so that coworkers can get in touch with one another. Business addresses and business phone numbers for sales representatives may be appropriate to reveal even without authentication, whereas the same individuals’ home addresses may not be appropriate to reveal even to authenticated users. Context is key.
• The Burp Suite extension, Autorize, is helpful for automating access control checks, particularly when the tester has access to multiple user accounts.

Tips for Developers – Preventing IDOR

• Every time a user accesses a resource or performs an action, a check needs to be performed to verify that the user is authorized to access that resource or perform that action.
• IDOR needs to be considered every time new code is deployed. Most of the time when I discover IDOR, access controls are enforced correctly 99% percent of the time, but one or two endpoints slip past any previously utilized quality checks and wreak havoc.
• Keep in mind that IDOR is a business logic flaw. Vulnerability scanners may be great at detecting things like cross-site scripting, but they aren’t going to pick up on nuanced logic such as “Customer A should have access to Customer B’s data, but not Customer C’s” data.
• Using unpredictable identifiers, such as GUIDs, may make IDOR more difficult to discover, but it is not a replacement for correctly enforcing security controls. If the GUIDs are disclosed anywhere in the application or sent over a URL, IDOR may still be exploited.
• Consider adding checks for IDOR as integration tests or acceptance tests as described here.

Hopefully this post has given you some things to think about regarding IDOR. Given how prolific and consequential this vulnerability is, we all need to do our part to keep an eye out for it.

---

---

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

---

---