Secure web application from ‘Insecure direct object references’

‘Insecure direct object references’ is ranked 4th on the list OWASP top 10 vulnerabilities 2013. Now days, it has become a serious concern for software development companies to maintain the privacy of all the users. This vulnerability breaches the authorization gates and allow an attacker to thieve unauthorized data from web application. Let’s have detailed understanding of this vulnerability.

What is insecure direct object references?

According to OWASP definition insecure direct object references occur when web application gives direct access to those objects which are based on user-supplied input. As a result, an attacker can bypass the authorization gates and gain the access of resources of the system directly, like database files and records.

This vulnerability allows the attacker to bypass authorization steps of an application and have the access of all the resources directly by modifying the values of parameter which is used to point an object. These kinds of resources can be files of system, entries belonging to other users, etc. This happens because the application takes user supplied input and retrieve an object without checking sufficient authorization.

How can you know you are vulnerable?

Here are some easy ways to find out if your web application is vulnerable or not.

• Does the application verify the exact user and the resources he is given access to? (For all direct references to restricted resources)
• Suppose the reference is an indirect reference, you need to verify if the mapping to the direct references fail to restrict the values for authorized current user.

Code review of any application by custom web application companies can identify whether we can apply either approach safely or not. In most of the cases manual testing is proved to be effective to identify direct object references and check whether they are safe or not. Automated tools generally cannot look for such flaws as they cannot distinguish protection what is safe and what is not.

Let’s have a demo website where an object id is 3 which can be seen like this.

Here is the object (A user profile)

Now if we just change id from id=3 to id=1 in URL, we can see that we are directly given access to that object on id=1.


 

Prevention

To prevent this vulnerability from your web application, web application software companies suggests to create a map with in your code that maps objects. These objects could be referenced internally to aliased terms which are exposed to the user. For example, an array of primary keys to a particular table might be mapped with random sequence of integers. When the value is submitted by user, the number is matched to a real value. This prevents disclosure of the actual value and also limits what a user can alter.

For example,

default             --> index.html

account_summary     --> account_summary.html

user_profile         --> user_profile.html

Values supplied by the user should be vetted through an access control function to verify that he is authorized for that data.

Bibliography

OWASP. (2014, August 8). Testing for Insecure Direct Object References. Retrieved from OWASP: https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)