Insecure Direct Object References Series: Prevention of Insecure Direct Object Reference

1. Access Control Check:
One essential defense is to check access control. On each use of a direct object reference from an untrusted source, the application should perform an access control check to ensure the user is authorized for the requested object or service. One way to implement this is to use role-based authorization. The idea behind is associating a list of roles with a user, and the service code queries the list to make decisions about whether the user has privilege to access the requested object or service at run time.
2. Indirect Reference Map:
An indirect reference map is a substitution of the internal reference with an alternate ID. It is used for mapping from a set of internal direct object references (i.e. database keys, filenames, etc. ) to a set of indirect reference that can be safely exposed externally
The direct references are user IDs that are integer and auto-incrementing. Take this as an example; an indirect reference map can be implemented as follows:

• a) Create a map on the server between that actual key, user ID in the database (i.e. 1011, 1012, ...), and the substitution, which can be a long hash value or a GUID that is easily generated but difficult to predicted by users
• b) The user ID is translated to its substitution key before being exposed to the UI.
• c) After the substitution key is returned to the server, it is translated back to the original user ID before the record is retrieved.

3. Use per user or session indirect object references.
This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server.
4. Don’t expose the actual ID/name of objects
5. Minimize user ability to predict object IDs/Names
6. Use of ESAPI

Insecure Direct Object References Series : Test/Detect Insecure Direct Object References Vulnerability

Generally, the first step of testing this vulnerability is to “map out all locations in the application where user input is used to reference objects directly” .These locations include where user input is used to access a database row, a file, application pages, etc. Secondly, modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users and whether authorization can be bypassed.

Static Analysis
One important approach is code review of the application and verifies whether the following mechanisms are implemented safely:
(1) For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
(2) If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.
Dynamic Analysis
One way to test would be by having multiple users to cover different owned objects and functions. For example, assume two users each having access to different objects and with different privileges (i.e. administrator users or normal users). Logon as one user to see whether there are direct references to objects or functionality that belong to other users. Another advantage of having multiple users is to save testing time in guessing different object names that belong to other users.
Typical scenarios for this vulnerability and the methods to test for each include:
The value of a parameter is used directly to retrieve a database record
Sample request:
                         http://foo.bar/somepage?invoice=12345
In this case, the value of the invoice parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
Since the value of invoice goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization.
The value of a parameter is used directly to perform an operation in the system
Sample request:
                         http://foo.bar/changepassword?user=someuser
In this case, the value of the user parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user's password is to be changed, and in the next step the user will provide a new password (without asking for the current one).
The user parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user.
The value of a parameter is used directly to retrieve a file system resource
Sample request:
                         http://foo.bar/showImage?img=img00011

In this case, the value of the file parameter is used to tell the application what file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users.
To test for this case, the tester should obtain a reference the user is not supposed to be able to access and attempt to access it by using it as the value of file parameter.
The value of a parameter is used directly to access application functionality
Sample request:
                         http://foo.bar/accessPage?menuitem=12
In this case, the value of the menu item parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1, 2 and 3. By modifying the value of menu item parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.
In the next part of the Insecure Direct Object References Series we will talk about some Insecure Direct Object Reference Prevention techniques

Insecure Direct Object References Series: Introduction and Why Vulnerability Occur

Introduction
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 Reference is an attack where attacker who is an authenticated system user, simply changes a parameter value that directly refers to a system object or another object the user isn’t authorized for. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place.

By 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 ID in a URL string to access the information of other users) . The potentially accessed resources can be database entries belong to other users, files in the system, and more
Why Insecure Direct Object References Vulnerability occurs
From the cases and examples presented above, we can see that insecure direct object typically caused by several design flaws, such as lack of access control, using direct reference to internal object that is exposed and predictable ( i.e. customer ID are easily guessed because it is integer and auto incrementing ).
In the next part of the Insecure Direct Object References Series we will talk about how to Test/Detect Insecure Direct Object References Vulnerability in the web application