- Security Testing Tutorial
- Security Testing - Home
- Security Testing - Overview
- Security Testing - Process
- Security Testing - Malicious Software
- HTTP Protocol Basics
- HTTPS Protocol Basics
- Encoding and Decoding
- Security Testing - Cryptography
- Security Testing - Same Origin Policy
- Security Testing - Cookies
- Hacking Web Applications
- Security Testing - Injection
- Testing Broken Authentication
- Testing Cross Site Scripting
- Insecure Direct Object Reference
- Testing Security Misconfiguration
- Testing Sensitive Data Exposure
- Missing Function Level Access Control
- Cross Site Request Forgery
- Components with Vulnerabilities
- Unvalidated Redirects and Forwards
- Security Testing - Ajax Security
- Testing Security - Web Service
- Security Testing - Buffer Overflows
- Security Testing - Denial of Service
- Testing Malicious File Execution
- Security Testing - Automation Tools
- Security Testing Useful Resources
- Security Testing - Quick Guide
- Security Testing - Useful Resources
- Security Testing - Discussion
Insecure Direct Object References
A direct object reference is likely to occur when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key without any validation mechanism which allows attackers to manipulate these references to access unauthorized data.
Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.
Example
The App uses unverified data in a SQL call that is accessing account information.
String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );
The attacker modifies the query parameter in their browser to point to Admin.
http://webapp.com/app/accountInfo?acct=admin
Hands ON
Step 1 − Login to Webgoat and navigate to access control flaws Section. The goal is to retrieve the tomcat-users.xml by navigating to the path where it is located. Below is the snapshot of the scenario.
Step 2 − The path of the file is displayed in 'the current directory is' field - C:\Users\userName$\.extract\webapps\WebGoat\lesson_plans\en and we also know that the tomcat-users.xml file is kept under C:\xampp\tomcat\conf
Step 3 − We need to traverse all the way out of the current directory and navigate from C:\ Drive. We can perform the same by intercepting the traffic using Burp Suite.
Step 4 − If the attempt is successful, it displays the tomcat-users.xml with the message "Congratulations. You have successfully completed this lesson."
Preventive Mechanisms
Developers can use the following resources/points as a guide to prevent insecure direct object reference during development phase itself.
Developers should use only one user or session for indirect object references.
It is also recommended to check the access before using a direct object reference from an untrusted source.