Insecure Direct Object References

Sunday, 12 August 2018

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.

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.

Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object.

For Example

All About Cross Site Scripting => Click on me :)
Learn about => Security-misconfiguration
Know about Critical Vulnerability => SQL Injection Click on me :)

1) Avoid exposing your private object references to users whenever possible, such as primary keys or filenames
2) Validate any private object references extensively with an "accept known good" approach
3) Verify authorization to all referenced objects

Insecure Direct Object References cases
Case 1: 
The value of a parameter is used directly to retrieve a database record

String query = "SELECT * FROM table WHERE cartID=" + cartID;

Case 2: 
Sometimes leads to Directory traversal or Path traversal
Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin", which may also be useful in accessing unexpected files. This is referred to as absolute path traversal.
In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated file name to widen the scope of attack. For example, the software may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.

../../../etc/passwd in part of linux

Directory Traversal

Assume a web application allows for a file to be rendered to a user that is stored on the local machine. If the application isn't verifying what files should be accessed, an attacker can request other files on the file system and those will also be displayed.

For instance, if the attacker notices the URL:
The attacker could modify the file parameter using a directory traversal attack. He modifies the URL to:**../../../etc/shadow**
Upon doing this the /etc/shadow file is returned and rendered by file.jsp demonstrating the page is susceptible to a directory traversal attack.

All About Cross Site Scripting => Click on me :)
Learn about => Security-misconfiguration

IMP =>
Exploiting Insecure Direct Object References, attackers can bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object ( i.e. by modifying the user account)

Exploit 1 :
Is there is URL is redirecting on parameter ID in a URL string to access the information of other users)
attacker can change the ID by predicting and and may redirect to another person account

Exploit 2 :
IF something is coming in directory
attacker can change the path and lead to LFI or path traversal or directory traversal
for example