Modern Web Hacking – Accessing Data through Insecure Direct References

hackers gonna hack.jpgIn times past, traditional web application security vulnerabilities were everywhere. To this day, it is very common to come across SQL injection and Cross-Site Scripting in older applications. Those vulnerabilities are commonly attributed to poor input validation and poorly formed SQL queries. If you need a refresher, Jason Johnson wrote a great introduction to SQL Injection for your reading pleasure.


While these vulnerabilities are still more common than they should be, modern programming practices have made it easier to develop secure code. From my experience, there is a big difference between applications written with and without a development framework.


Frameworks
Frameworks, such as ASP.NET, Django, Symphony, and Zend, exist to help a developer focus on creating value without having to re-invent the digital wheel. While each framework will have its strengths, they commonly assist with user authentication, database communication, development design, and more.


One of the most common tasks a developer will have to perform is reading and writing to a database. Through the use of an ORM (Object Relational Mapper), the framework will both simplify and secure this process.

 

By using the framework’s standard method of communicating with the database, an application can securely accept user input and avoid SQL Injection issues. This works because the framework can formulate the SQL query in a secure manner.

 

Now What?

Now that the rise of frameworks has reduced one of my favorite attack vectors, what should a modern hacker do? Don’t despair, Insecure Direct Object Reference comes to the rescue!
The name probably needs a marketing makeover. However, Insecure Direct Object Reference (IDOR for short) takes advantage of application specific logic flaws to gain access to additional information.


Simple Example
This first example is very obvious and does a great job of illustrating the problem. Suppose you just finished placing an order online and noticed that the order confirmation page looked like:

 

https://vulnerable.example.net/sales/order.php?id=1328

 

My first instinct would be to change the “id” parameter by one digit to see if I can see someone else’s order. Here is what the edited URL would look like:

 

https://vulnerable.example.net/sales/order.php?id=1327

 

If you are taken to someone else’s confirmation order page, you have just found an Insecure Direct Object Reference.


How does it work?

The developer is trusting the value for “id” and using that value to directly reference a row in the database. The “insecure” portion happens when the developer fails to check if the user has permission to that other order confirmation.


Obscure Example

The previous example was fairly obvious. Personally, it appears to be more common for a developer to use some form of an ID in a hidden field. In a recent engagement, I came across a website that allowed users to create accounts. In the profiles section, it also allowed the user to delete their own account.


Now, keep in mind that after logging in, the web application should know who I am. As long as I’m logged in, it doesn’t need to be reminded that I’m user 27501. When I would like to delete my account, I should simply have to say “delete me” and it would know what account to delete.


However, in this particular application, when I clicked on the “Delete me” button, my web browser sent a variety of interesting information back to the server. One of the hidden parameters sent was a code that appeared to be a user ID.

 

<input type=”hidden” name=”myUID” value=”27501”/>

 

 

So guess what I did? I used an intercepting web proxy to capture the data going from my web browser to the web server. Next, I clicked on the “Delete me” button and intercepted the web request. On my proxy, I changed the request from 27501 to 27500 and then forwarded the request.


When I tried to log in with the account that used the 27500 ID, I discovered that the account no longer existed. Can you imagine how devastating it would have been to the site if I had created a script to automatically delete every account?

 

Solutions
So what should a developer do to protect themselves against Insecure Direct Object References? There are a number of solutions that are appropriate in different situations:

 

  • Do not trust what the users tell you. Check that the user ID 27501 actually belongs to the person making the request.
  • Another option is to remove the ability for a malicious user to modify a request and to do bad things. In the last example, it really wasn’t necessary for me to tell the web application what my account ID was. The application should use the information it knows instead of trusting input from the user.
  • Another interesting option that I have seen lately is the use of GUIDs. A GUID is a very long and unique number. Because GUIDs are unique and generated randomly, it is extremely impractical to guess. Had the website used GUIDs instead of sequential ID’s, it would have prevented me from deleting other accounts with unknown GUIDs.
  • Finally, another option is to use Indirect Object References. A detailed description of Indirect Object Reference can be found on the OWASP web page.

 

Conclusion
Now that you can spot an IDOR, you can make the world a safer place! Comments and questions are greatly appreciated!

Labels: Fortify
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Lucas Gates is an Advanced Dynamic Tester with the Fortify On Demand team who enjoys responsible hacking.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.