Protect Web applications from direct object reference (DOR)

Imagine that a malicious hacker can access the account details of all the customers in your company, or use another person's credit card for online shopping. All this requires only a few digits in the URL. This sounds unlikely, but if your Web application is vulnerable to insecure direct object references, it is easy for malicious hackers to achieve this.

Example of unsafe direct object reference

Here, "object" refers to objects implemented internally, such as files, directories, and database records. When an application exposes a reference in URL or form parameters to these objects, security issues may occur. This is because hackers can modify these direct object references. For example, hackers can modify parameters before a URL is submitted to attempt to access different unauthorized files and directories, or an entry in the database. If other authorization checks are not strengthened, such attempts will succeed.

Assume that a Web application will generate the following URL:

Http://www.yourinsecurewebapp.com/yourgetfile.cfm? Filenameextyoursometextfile.txt

There is a very explicit direct object reference to the yoursometextfile.txt file. .

To achieve this success, hackers must correctly guess another file name on the system, but a more reasonable method is to find specific content from other locations on the system, the method used is directory traversal. Directory Traversal is a security vulnerability in Http, which allows attackers to access restricted directories, and can execute commands outside the root directory of the Web server .). Essentially, this means accessing a completely different directory, or any aspect built by developers of Vulnerable applications. To access Apache Tomcat file names and passwords, hackers may change the last part of the URL:

 
 

  
  
?filename=../../tomcat/conf/tomcat-users.xml  
 
 

Not all direct object references provide access to files. There is another URL that may interest hackers. Its end format is as follows:

 
 

  
  
...account.cfm?customerid=4567 
 
 

This will allow the hacker to further ask, "what will happen if I change the customer IDcustomerid to 4568 ?"

Similarly, if a Web application allows a user to reference one or more credit cards stored in the database based on the database keyword, when a hacker modifies the keyword of the database, what will happen?

 
 

  
  
<select name="choosecreditcard"> 
  
  
 
  
  
<option value="56"> 
  
  
 
  
  
XXXXXXXXXXXX6902  
  
  
 
  
  
</option> 
  
  
 
  
  
<option value="88"> 
  
  
 
  
  
XXXXXXXXXXXX5586  
  
  
 
  
  
</option> 
  
  
 
  
  
</select> 
 
 

Here, you can select one from two cards ending with 6902 and 5586 respectively. This card number is referenced by the database keyword, and the application can access this database file. Therefore, hackers can change 56 or 88 to another number, such as 78, to reference the card number of another user. If there is no other authentication check to prevent such reference, the attack will be successful.

Avoid unsafe direct object reference

The best way to avoid unsafe direct object references to the "DOR" vulnerability is to avoid exposing private object references at all, but if it is not available, it is important to ensure that access is authenticated and reviewed before access is provided to any user. OWASP, the world's top Web Application Security Organization, recommends that enterprises establish a standard method to reference application objects. The following is a brief description:

1. Try to avoid exposing private object references to users, such as important keywords or file names.

2. Use an acceptable good method to verify in detail any private object reference. Determine which files are accessible to users and grant them only the right to access these files.

3. Verify all referenced objects.

OWASP also provides an example of the third key point. Here, hackers can change the shopping cart ID parameter of an e-commerce website to any value:

 
 

  
  
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );  
  
  
 
  
  
String query = "SELECT * FROM table WHERE cartID=" + cartID; 
 
 

To prevent such attacks, only the authorization records can be displayed:

 
 

  
  
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );  
  
  
 
  
  
User user = (User)request.getSession().getAttribute( "user" );  
  
  
 
  
  
String query = "SELECT * FROM table WHERE  
  
  
 
  
  
cartID=" + cartID + "AND userID=" + user.getID(); 
 
 

Another option for direct object reference is that each user or session uses a non-direct object reference.

In the previous example of a credit card, you need to select a credit card from the two cards, which exposes direct reference to the credit card database. A better way is to store the two credit card records in a specific array for this user. The code for choosing a credit card is similar to the following:

 
 

  
  
<select name=" choosecreditcard"> 
  
  
 
  
  
<option value="1"> 
  
  
 
  
  
XXXXXXXXXXXX6902  
  
  
 
  
  
</option> 
  
  
 
  
  
<option value="2"> 
  
  
 
  
  
XXXXXXXXXXXX5586  
  
  
 
  
  
</option> 
  
  
 
  
  
</select> 
 
 

In this method, only one direct reference to this user array contains only the data of this user. Changing the option value to a value greater than 2 will not cause other users' credit card details to be exploited. Then, the application will map the user-specific non-direct object reference option value to 1 or 2) back to the underlying database keywords 56 and 88 in the previous example)

Test of unsafe direct object reference

Unfortunately, the vulnerability scanner is not very efficient in discovering insecure direct object reference vulnerabilities, so the best choice is:

1. Check the code carefully to check whether important parameters are easy to use and manipulate.

2. conduct professional penetration tests frequently.