Insecure Direct Object Reference is a vulnerability that occurs when developers expose references to internal implementation objects like files, directories or database keys without access control checks. Attackers can manipulate these references to access unauthorized data. The document discusses the definition, scenarios, detection and protection methods for this vulnerability. It recommends using indirect object references or access control checks on direct references to protect against insecure direct object references.

1. Insecure Direct Object Reference
Obay Osman
OWASP Khartoum
15 Sept 2012
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

2. Will talk about…
• Definition.
• OWASP’s Rating.
• Scenarios.
• In the wiled.
• Demo time.
• Detection & Protection.
• Warp Up.
• Q & A.
2

3. Definition
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.
3

4. OWASP Risk Rating #
4

5. Simple Attack Scenario
//BAD - DON'T USE --- Reference to DB key
public void displayInfo(){
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatementpstmt=connection.prepareStatement(query , …
);
pstmt.setString( 1, request.getParameter("acct"));
ResultSetresults = pstmt.executeQuery( );
...
}
Attacker:
http://example.com/app/accountInfo?acct=notmyacct
5

6. Simple Attack Scenario
//BAD - DON'T USE --- Reference to file
<select name="language">
<option value="fr">Français</option>
…..
</select>
… require_once ($_REQUEST['language’]."lang.php");
Attacker:
../../../../etc/passwd%00
6

7. In the wield..
- Australian Taxation Office.(a company tax id)
- 17,000 companies affected.
Methodologies: Parameter Tampering,
Path Traversal, Null Byte Injection…
7

8. Let ‘s have some fun…
8

9. Detection
Verify that all object references have
appropriate defenses:
1.Direct references:
verify the user is authorized to access the
exact resource they have requested.
2.Indirect references:
the mapping to the direct reference must
be limited to values authorized for the
current user.
9

10. Detection
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.
10

11. How to Protect Yourself
Protect each user accessible object (e.g.,
object number, filename):
1.Use per user or session indirect object
references.
2.Check access of direct object reference
from an untrusted source, to ensure the
user is authorized for the requested
object.
11

12. OWASP’s Recommendation
OWASP’s ESAPI includes both sequential
and random access reference maps that
developers can use to eliminate direct
object references.
OWASP’s ESAPI Access Control API.
Meet all requirements defined in OWASP’s
ASVS areas V4 (Access Control).
12

14. OWASP Top 10 2010:
A1 –Injection
A2 –Cross-Site Scripting (XSS)
A3 –Broken Authentication and Session Management
A4 –Insecure Direct Object Reference
A5 –Cross Site Request Forgery (CSRF)
A6 –Security Misconfiguration(NEW)
A7 –Insecure Cryptographic Storage
A8 –Failure to Restrict URL Access
A9 –Insufficient Transport Layer Protection
A10 –Unvalidated Redirects and Forwards (NEW)
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

15. Ref.
• OWASP Top 10-2007 on Insecure Dir Object
References
• ASVS requirements areas for Access control (V4)
• OWASP Authentication Cheat Sheet
• ESAPI Access Control API
• ESAPI Access Reference Raps
• OWASP Development Guide: Chapter on
authentication
• OWASP Testing Guide: Chapter on Authentication

16. 16