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