Securing Node Applications

Chapter 4. Insecure Direct Object References

The insecure direct object references vulnerability allows an attacker to steal other users’ data of a specific type. Beyond just the data in a database, an attacker can exploit it to access restricted files or directories on the server. According to the Open Web Application Security Project (OWASP), an insecure direct object references vulnerability is commonplace and easy to exploit.

So, what makes an application vulnerable to this attack? As the name indicates, it is caused when a direct reference (such as a database ID or a filename) to a restricted object is exposed to users as part of the URL parameter. In addition, the application fails to verify whether the user is authorized to access the requested object for which the reference is present in the request URL.

Let’s examine some specific attack vectors and ways to mitigate them.

Attack Mechanics

In this exploit, attackers manipulate the identifier in the request URL to access other records in the database that do not belong to them. For example, consider this URL on a vulnerable application:

www.example.com/profile/3032

In this URL, 3032 is an ID of a profile record in the database. Because it is exposed in the URL and predictable, an attacker can simply change it to some other value and access other users’ restricted profiles.

Here is an another example of using a URL to retrieve a filesystem resource:

www.example.com/reports?name=feb2016report.pdf

The name parameter in this URL specifies the exact filename to retrieve. Attackers can modify this predictable parameter to access reports for other months, for which they have neither paid nor are subscribers.

Preventing Insecure Direct Object References

The following subsections present some concrete measures to prevent insecure direct object references.

Avoid Exposing Direct Object References

Instead of requiring the references in the URL, use the information already present in the user’s session on the server to locate the resources to serve. For example, in the www.example.com/profile/3032 route implementation we just reviewed, if the users are allowed to access only their profile, we can use the logged-in user’s ID in the session to locate it, thus eliminating the need for passing id as a URL parameter.

Use an Indirect Reference Map

If it is not possible to avoid exposing the references to objects in the URL, as explained earlier, the indirect reference map technique is helpful. The idea behind it is to substitute the sensitive direct internal reference in URL parameters or form fields with a random value that is difficult to predict (such as a GUID) or specific only to the logged-in user (such as sequential values per user or session).

The indirect reference map stores mapping between an object’s internal reference and corresponding indirect reference exposed in the URL. For Node applications, the indirect reference map can simply be a JavaScript object stored in a user’s session. When rendering an object in a view template, use the mapped indirect references instead of direct references. In the other direction, when a user request contains an indirect reference, refer to the indirect reference map to look up and retrieve the corresponding internal reference and use it for further processing.

The OWASP Enterprise Security API project provides a good reference implementation for indirect reference map in Java to get a better idea of how to implement it.

Check User Access at the Data-Object Level

This defense mechanism addresses the primary issue causing the vulnerability: an insufficient or missing access check.

First, never rely only on client-side validations for access control, because an attacker can easily circumvent those.

Second, while implementing the server-side access controls, it is relatively obvious to add authorization checks at the functionality or route level. Unfortunately, many applications stop at that level. A common issue that causes this vulnerability is missing access checks at the data or object level to protect against tampered IDs in URL parameters. You need to enforce the data layer access controls by verifying that the current user owns or is allowed to access the requested data.

Directory Traversal

The directory traversal is a special case of the insecure direct object references vulnerability, in which an attacker manipulates the path exposed in a URL to access directories and files outside of the web root folder and possibly compromise the entire web server.

To exploit it, an attacker uses absolute or relative path traversal characters such as /, ../, or its encoded versions %2f, %2e%2e%2f, or %2e%2e/ to manipulate the path.

Protecting Against Directory Traversal

To prevent the directory traversal attack, you need to take measures at the system-configuration as well as the application-code level:

• At the system-configuration level, configure the root directory and access control list to confine the application user’s access and restrict access to files and directories outside of the web root.

• In the application code, validate user inputs for presence of path traversal and corresponding encoded characters.

Directory Traversal Vulnerability in Node Modules

The directory traversal vulnerability is commonplace in Node.js applications. The Node Security Project found and reported directory traversal vulnerabilities in multiple modules. Here are some examples:

• The classic exploit using ../ in user input is possible in fancy-server (<0.1.4) and nhouston Node modules.

• Versions prior to 0.2.5 of the st module are vulnerable to leaking sensitive data from the server with encoded path traversal characters, such as /%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd.

• A slight variation of directory traversal was spotted in the send(< 0.8.4) Node module, in which an attacker could access files in a similarly named restricted directory. For example, a configuration like static(_dirname + '/public') would allow access to the _dirname + '/public-restricted' directory.

Conclusion

The internal references to objects such as database IDs or filenames are often exposed publicly as part of the URL parameters. The techniques to prevent insecure direct object references primarily focus on protecting these references as sensitive data and checking access control at the data-object level.

Additional Resources

• “Testing for Insecure Direct Object References”

• “Meteor Security in the Wild”