Security Code Review 101 — Indirect Object Reference

How to prevent Path Traversal, Authorization Bypass and even Open Redirect with a simple programming strategy

This is the final article in the Security Code Review 101 series. Read the previous article on Cross-Site Scripting or start from the beginning.

Graphic describing strategy to access objects indirectly, using identifiers.

Preventing Path Traversal

Path Traversal, AKA Directory Traversal, AKA File Manipulation, is one of the oldest and most commonly encountered software security flaws. It is listed in the SANS Top 25 at #13 and is included in the OWASP Top 10 at #5 under Broken Access Control.

Path Traversal is also known as a dot dot slash attack. The attacker takes advantage of a file path exposed in the software and under user control, to traverse out of the application directory and expose or overwrite sensitive system files.

The following attack-gram describes this scenario:

Diagram describing a Path Traversal attack

Let’s take a look at a couple of code snippets. Which one is allowing the attack and which one is preventing it?

Code snippets for an application that manipulates files.

If you chose top.jsp as the vulnerable code you were correct. That code takes the file name from the user and without any validation concatenates it to a public directory. Then it returns the contents of the resulting file path. If the attacker enters ../../../../../../../../etc/passwd the file path then becomes /public/../../../../../../../etc/passwd and the attacker will be served an operating system file instead. Because the file object is being accessed directly this is also known as a direct object reference.

In contrast bottom.jsp is using a file identifier to map the requested file to an allowed collection of file paths. The file is accessed indirectly preventing the Path Traversal attack and is an example of leveraging the Indirect Object Reference strategy.

This best practice can be used in a similar way to prevent other software flaws.

Preventing an Authorization Bypass Scenario

Imagine an application that has a report generation function for confidential business data. The report generation page includes an e-mail parameter which specifies the address where the report will be sent when ready.

The attacker e-mails a legitimate user of the system a link including an unauthorized e-mail address: https://site.com/sendreport?email=attacker@evil.bad .The application will then e-mail the report to the attacker.

If the application instead using a user id to determine where to send the report, the attack is mitigated: https://site.com/sendreport?userId=42

Preventing Open Redirect

Open Redirect is another SANS Top 25 item, at #22. Open Redirect allows attackers to leverage legitimate sites to trick users into downloading malware or provide confidential information.

The attack-gram below describes the scenario:

Diagram describing a phishing attack where a trusted site redirects to a malicious one

Open Redirect is made possible by code that allows the redirect URL to be controlled by the user.

For example a redirect to a single sign on service will reference the full URL of the service: https://site.com/login?sso=https://adfs.corporate.com

The attacker will leverage this functionality with the following link: https://site.com/login?sso=https://adfs.site.com.evil.bad

However if the application references the SSO by id instead the attack is mitigated: https://site.com/login?ssoid=APAC_ADFS

To sum at all up…

The Indirect Object Reference strategy helps prevent vulnerabilities such as Path Traversal or Open Redirect because resources are accessed indirectly, through an intermediary identifier.

By limiting the set of objects to an authorized collection this best practice also helps mitigate logical abuses and authorization bypasses.

This best practice also has the following benefits:

• Prevents transmission of potentially sensitive data in URLs. Ex. instead of userEmail=john.doe@company.com use userEmailId=42.
• Input validation is easier to do. If the parameter is numeric or a GUID, validation is more straightforward than having to validate a person name or file path.

Test Your Skill

Do you think you can identify security flaws during regular code reviews? Test your skill by solving this quiz .

More Resources

The Secure Coding Dojo is an open source training platform that is dedicated to teaching developers about programming flaws, exploits and secure coding practices. Follow the project on Github and try out the application using docker-compose.

Attack-Grams are a set of diagrams explaining basic security flaws. Check them out here: https://medium.com/@paul_io/attack-grams-137d99772d07 . You’re free to use them in your own presentations and training materials. You can find the source material in the Secure Coding Dojo repo.

Keep in Touch

Did you like the article and want to be notified of similar content in the future? Let’s keep in touch:

• Follow the Secure Coding Dojo project on Twitter: https://twitter.com/SecureCodeDojo

Happy coding :) !

The Complete Security Code Review 101 Series

• Input Validation — https://medium.com/@paul_io/security-code-review-101-input-validation-f309b1be96c7
• Parameterized Statements — https://medium.com/@paul_io/security-code-review-101-parameterized-statements-df95c264364a
• Memory Safe Functions and Safe Memory Management practices — https://medium.com/@paul_io/security-code-review-101-memory-adf0543926ee
• Protecting Data — https://medium.com/@paul_io/security-code-review-101-protecting-data-part-1-23e810277f7d and https://medium.com/@paul_io/security-code-review-101-protecting-personal-data-f2e891a6ff13
• Protecting Against Cross-Site Scripting — https://medium.com/@paul_io/security-code-review-101-protecting-against-cross-site-scripting-387fb188aa2e
• Indirect Object Reference — https://medium.com/@paul_io/security-code-review-101-indirect-object-reference-91f3ad0451c5