Top Ten Web Security Risks: Insecure Direct Object References (#4)

Finding all the references can be difficult

Today we are going to learn about number four on the Open Web Application Security Project (OWASP) top ten list, insecure direct object references. Have you ever noticed a parameter in a URL and tried tweaking it to retrieve a different valid page? If you were successful, you exploited an insecure direct object reference.

If you’ve been keeping up with our OWASP Top Ten series, you might be thinking we’ve already covered this with the www.diary.example.com?user=somebodyElse example in number seven’s missing function level access control. And, you’d be fundamentally right that the example is the same, however there are two distinctions that set this vulnerability apart, though it’s closely related to missing function level access control.

Defining the Problem

The first distinction is that this vulnerability directly accesses data, as opposed to a function that returns data. This could potentially give the attacker full control over the object as opposed to functions that interact with the object.

The second distinction is that this reference is “direct” as opposed to being encapsulated through a function. Let’s use another analogy to highlight the distinction. In the first example of missing function level access control, I (the hacker) want to schedule a meeting with you (the object). However, I have no “direct” contact with you, so I exploit a connection with your personal assistant (the function) to schedule a meeting. However, if I, as the hacker, am able to exploit an insecure direct object reference, it means I was able to corner you in the elevator to set up a meeting.

Below is the OWASP cheat-sheet on insecure direct object references:

Detection & Prevention

Code reviews, application analysis, and testing are the best ways to detect these vulnerabilities. Automated tools can also be used to help assist in scanning, however they are insufficient by themselves as they have difficulty identifying what is important to secure and/or what is safe/unsafe.

Now there are two primary ways to prevent being cornered in the elevator and coerced into a conversation. First, avoid direct object references all together. This would mean absolutely no strangers would be allowed to talk to you directly, but would be forced to communicate with you through intercessors (or indirect references). This has the advantage of making it difficult or highly improbable for attackers to be able to predict object references and gain unauthorized access. OWASP’s ESAPI library includes reference maps for developers to ease the implementation of this method for developers.

The second method for preventing indirect object references is to enforce access control to these objects. Simply check to make sure the user is authenticated and authorized to use the objects prior to allowing them access. Similarly, there are security mechanisms for most frameworks to aide developers in implementing this approach. However, as discussed in our last post in the series, these still must be carefully configured.

Summary

Protecting your data is important, and insecure direct object references are a true threat. Thankfully, there are two tried and true best practices for preventing them. Both approaches have different use cases depending on the design of your application, and they are not mutually exclusive. And as always, repeatable processes are important for continued vigilance in securing your data.

Credera has a security team that is well versed in the detection and prevention of security holes and application vulnerabilities. If you would like to discuss any of the materials you have read or have a particular need for testing or secure application development, please email us at SecurityTeam@credera.com

• OWASP
• Web Security Risks
• Open Web Application Security Project
• Insecure Direct Object References