Security Insecure Direct Object References

security

https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.html
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html
https://www.owasp.org/index.php/ASVS
http://cwe.mitre.org/data/definitions/639.html
http://cwe.mitre.org/data/definitions/22.html

// Security - Insecure Direct Object References:

In a REST application, we typically expose the ID of an object.  For example,
/order/... may display the content of that order, or /person/... may display 
information for that particular user. A mal-intent user can change the ID in 
the URL, and without proper access validation on the server, the server may 
display the page even though this mal-intent user should not have access to that 
resource.

Code review of the application can quickly verify whether either approach is 
implemented safely. Testing is also effective for identifying direct object 
references and whether they are safe. Automated tools typically do not look for 
such flaws because they cannot recognize what requires protection or what is 
safe or unsafe.

To Prevent 'Insecure Direct Object References':

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. The application has to map the per-user indirect reference 
   back to the actual database key on the server. OWASP’s ESAPI includes both 
   sequential and random access reference maps that developers can use to 
   eliminate direct object references.

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.

Example of Attack Scenarios:

Consider this code:

String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , … );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

The attacker simply modifies the ‘acct’ parameter in their browser to send 
whatever account number they want. If not verified, the attacker can access 
any user’s account, instead of only the intended customer’s account:
http://example.com/app/accountInfo?acct=notmyacct
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License