Protect Your Web Apps From Insecure Direct Object References - Page 2

 By Paul Rubens
Page 2 of 2   |  Back to Page 1
Print Article

Avoiding insecure direct object references

The best way to avoid insecure direct object reference vulnerabilities is not to expose private object references at all, but if they are used then it is important to ensure that any user is authorized before providing access to them. OWASP www.owasp.org recommends establishing a standard way of referring to application objects as follows:

  • Avoid exposing your private object references to users whenever possible, such as primary keys or filenames
  • Validate any private object references extensively with an "accept known good" approach. This means determining what files a user should be allowed to access, and only granting them access to those files
  • Verify authorization to all referenced objects

An illustration, of this third point, also provided by OWASP, comes from a code sample in which a hacker could change an ecommerce cart ID parameter to any value:

int cartID = Integer.parseInt( request.getParameter( "cartID" ) );

String query = "SELECT * FROM table WHERE cartID=" + cartID;

This can be prevented by only allowing authorized records to be shown:

int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
User user = (User)request.getSession().getAttribute( "user" );
String query = "SELECT * FROM table WHERE 
   cartID=" + cartID + " AND userID=" + user.getID();


An alternative to direct object references, which should be used whenever possible, is to use per user or session indirect object references.

In the example earlier a user was asked to select a credit card from a choice of two which exposed direct references to the database of credit cards. A better method would be to take the two credit card records and store them in an array specific to that user. The credit card selection box would be coded like this:

    <select name=" choosecreditcard">
           <option value="1">
           <option value="2">

This way there is only a direct reference to an array for that user, containing only that user's data. Changing the option value to a value greater than 2 would not result in any other user's credit card details being used. The application would then map the user specific indirect object reference (option value=1 or option value=2) back to the underlying database key (35 or 67 in the example earlier.)

Testing for insecure direct object references

Unfortunately vulnerability scanners are not very effective at finding insecure direct object reference vulnerabilities, so the best options are:

  • code reviews to identify whether important parameters are susceptible to manipulation
  • penetration testing
This article was originally published on Mar 8, 2011
Get the Latest Scoop with Networking Update Newsletter