A4 Insecure Direct Object References
A4 Insecure Direct Object References
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
4.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.
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.html
4.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.
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html
Learn More:
- OWASP Top 10-2007 on Insecure Dir Object References
- ESAPI Access Reference Map
- ESAPI Access Control API (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction())
- CWE Entry 639 on Insecure Direct Object Reference
- CWE Entry 22 on Path Traversal (an example of a Direct Object Reference attack)