How do indirect, session-specific resource tokens increase security?

Question

The OWASP web site recommends this:

1. Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. [italics mine]
2. Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object. [italics mine]

So if a user doesn't have access to the requested resource, how does obfuscating the direct object reference improve security?

Given the increased complexity that, say, an ASP.NET MVC site would accrue, is this worth the additional trouble for anything but banking sites?

Answer 1

I will explain this by giving an example:

Suggest you have a list of objects in your database named:

• Pear
• Apple
• Orange

You have a query which fills up a hash table stored in your session which maps the fruits you are authorized to have to a number:

• 1 => Pear
• 2 => Apple

You do not have access to Orange. You then have a function which allows you to add fruits to a basket, so you choose a number 1 or 2 (this is the indirect object reference). Orange is not accessible in this session as it's not present in the hashtable (there is no number 3). With direct object reference you would have a function which just uses Apple, Pear, Orange rather than a number. So you could abuse the function (if no access controls are used) to add the Orange to your basket as well.

I personally do not see issues with direct object reference IF adequate access controls are in place. These access controls should be tested extensively. There might be more critical applications than others where this might be required, but imagine applications where there are thousands of users with each 100 or 1.000 options unique to them. Storing all of these in a session could have a significant impact on performance (considering the server will need to store this information for each client on the webserver).

Now to answer your first question: simply because it won't be loaded into the session. As in my hashtable example you simply won't have orange available.

Answer 2

I think you defined a reference object as an absolute and associated with finance. How about the following: You are a software vendor, your sw if sold online after a visitor purchases it. Wouldn't you prefer that ONLY the purchaser be able to access a hyperlink for your product?

Forget the financial (banking sites) or even software, what about say a social network. "Back in the days" if you sniffed the wire, it was a known fact you could pull out the URIs from the tcp capture, open it in a browser, and you had instant access to email, social network components, etc.

There are plenty of different scenarios you'd need it. Think about it for what it is: "Insecure Direct Object" an object directly accessible and cannot be secured for whatever reason. We need to secure it by assigning it a "reference" so it can never be "directly named."