The document discusses insecure direct object references (IDOR) and their implications in information security, highlighting how developers can unintentionally expose access to internal objects without proper checks. It emphasizes the need for access control validations in web applications to prevent unauthorized access and provides examples and prevention techniques for developers. Additionally, it references OWASP guidelines and various sources for further information about IDOR vulnerabilities.

1. Insecure Direct
Object References
Melissa Canazon
How do you refer to secure
information?
IT6873 Information Security
Seminar – Fall 2014

2. 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.”
~ OWASP
* Formally defined by OWASP, but what does this mean?

3. Path to Understanding
Defining “Objects”
Defining “References”
Defining “Insecure”
What does ‘insecure direct object reference’ mean?
- examples
How can it be used?
Prevention
Topic 1
Topic 2
Topic 3
Topic 4
Topic 5
Topic 6
Topic 7
How is it detected?

4. Definition: Objects

5. OBJECTS
data, information, files, images, video, resource, etc.
*can be stored and retrieved in either an unprocessed or
processed format

6. Definition: References

7. REFERRING TO OBJECTS
DIRECTORY
www.directory.com
OBJECT 1
www.directory.com/object1
OBJECT 2
www.directory.com/object2
OBJECT 3
www.directory.com/object3

8. Definition: Insecure
Authentication vs. Authorization

9. AUTHENTICATION vs AUTHORIZATION
CERTIFIED
AUTHENTIC
USER

10. Defining ‘Insecure Direct Object Reference’

11. Object1
www.some.com/access/authorizeduser/object2
www.some.com/access/unauthorizeduser/object1

12. How Can You Use Direct Object References?
• inurl: admin
• inurl:cgi
• filetype: pdf
• “auth_user_file.txt”
• index of ftp +.mdb allinurl:/cgi-bin/
+mailto

13. How Can You Use Direct Object References?

14. How Can You Use Direct Object References?
dot dot slash
.../
• Moving down the directory
• Some apps prevent this type of traversal,
so alternately:
• %2e%2e%2f which translates to ../
• %2e%2e/ which translates to ../
• ..%2f which translates to ../
• %2e%2e%5c which translates to ..

15. Detection

16. Prevention
Just a friendly reminder to developers:
INPUT IS EVIL!

17. INPUT IS EVIL
Input can be
malicious,
always validate
it before you
trust it!

18. User input
Direct
Reference
USER
SESSION
Reference Mapping
Indirect
Resource
Reference
Web app
sends
resource
User receives
resource &
indirect
reference
Web app
receives
request
Reference
Map
Generated

19. Spoiler Alert!
Access Control

20. Check out A7-
Missing Function
Level Access
Control!
Most web
applications verify
function level
access rights
before making that
functionality
visible in the UI.
However,
applications need
to perform the
same access
control checks on
the server when
each function is
accessed.
If requests are not
verified, attackers
will be able to
forge requests in
order to access
functionality
without proper
authorization.
ACCESS CONTROL

21. Check out A10-
Unvalidated
Redirects and
Forwards!
Applications
frequently redirect
users to other
pages, or use
internal forwards
in a similar
manner.
ACCESS CONTROL
Sometimes the
target page is
specified in an
un-validated
parameter,
allowing
attackers to
choose the
destination
page.
Unsafe forwards
may allow access
control bypass.
What if
attackers can
access internal
only functions?

23. OWASP Top 10 Threats and Mitigations
http://michaelpeters.org/quiz/
I challenge you to take the quiz
and share your thoughts!
Post in the discussion board!
Thanks to Albena and Aaron for
being my resource reviewers!

24. REFERENCES
1. CWE-22: Improper Limitation of a Pathname to a Restricted Directory. 30 July 2014. CWE
Common Weakness Enumeration. Retrieved from: http://cwe.mitre.org/data/definitions/22.html
2. CWE-639: Authorization Bypass Through User-Controlled Key. 30 July 2014. CWE Common
Weakness Enumeration. Retrieved from: http://cwe.mitre.org/data/definitions/639.html
3. CWE-706: Use of incorrectly resolved name or reference. 30 July 2014. CWE Common Weakness
Enumeration. Retrieved from: http://cwe.mitre.org/data/definitions/706.html
4. Hacking Websites Using Directory Traversal Attack. September 2012. HackingLoops.com.
Retrieved from: http://www.hackingloops.com/2012/09/hacking-websites-using-directory-traversal-attacks.
html
5. Melton, John. 10 May 2010. The OWASP Top 10 and ESAPI – Part 4 – Insecure Direct Object
References. Retrieved from: http://www.jtmelton.com/2010/05/10/the-owasp-top-ten-and-esapi-part-
5-insecure-direct-object-reference/
6. Mukherjee, Sumantro. 2 April 2013. Google Hacking: A Must Read Article. Hackshark. Retrieved
from: http://hackshark.com/?p=1058#axzz3EgMnLtXk
7. OWASP. 8 AUGUST 2014. Testing for Insecure Direct Object References. Retrieved from:
https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-
004)
8. OWASP. 14 June 2013. Top 10 2013-A4-Insecure Direct Object References. Retrieved from:
https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
9. Peters, Michael. 25 December 2012. Pop Quiz! Test your OWASP knowledge and earn credit.
MichaelPeters.org. Retrieved from: http://michaelpeters.org/quiz/
10. Redkar, Vinesh. 13 June 2013. NOKIA – Insecure Direct Object Reference. AVs3curity. Retrieved
from: http://avs3curity.blogspot.com/2013/06/nokia-insecure-direct-object-reference.html