Menu

Introduction to PCI DSS (Payment Card Industry Data Security Standard)   Introduction to PCI DSS (Payment Card Industry Data Security Standard)   

Data Protection Act 1998   Data Protection Act 1998   

Secure HTML Practices   Secure HTML Practices   

SQL Injection Attack - Introduction and Mitigation Steps   SQL Injection Attack - Introduction and Mitigation Steps   

Cross Site Scripting (XSS) – Introduction and Mitigation Steps   Cross Site Scripting (XSS) – Introduction and Mitigation Steps   

Audit and Testing Tools for Web Application Security   Audit and Testing Tools for Web Application Security   

Threat Modeling for Web Application Security - Practice Guide   Threat Modeling for Web Application Security - Practice Guide   

Insecure Direct Object References – Introduction and Mitigation Steps

Published on: 8/17/2014
Topic: Web Application Security
The Insecure Direct Object References represent the flaws in system design where access to sensitive data/assets is not fully protected and data objects are exposed by application with assumption that user will always follow the application rules. For example let’s take a scenario where an financial data report displayed to an user who is authorized to see his personal/organization’s financial data report but not expected to see other users/organization’s data. The flawed design would be if the web page uses an report id/filename that is available in webpage URL or in some hidden field. If report ID/Filename is obviously predictable then any user can change this ID/Filename and resubmit the request to see other users/organization’s data.


Table of Contents

How to identify and Prevent Insecure Direct Object References

Identifying this vulnerability is slightly more difficult using Automation tools than other vulnerabilities because to exploit this vulnerability you not only need to identify the flawed interface but also need to predict the pattern to identify an secure object like Filename etc.

The code review and website walkthrough may be done to identify such interface that provide access to sensitive contents and then verify that the object is not directly accessible based on predictable factors like Email id ,User Id, Customer Id, Predictable File names or obvious object names like Financial Reports named with Org./client name.

The common implementation areas where these objects may be exposed are URL & Links, Hidden Variables, Unprotected View State (ASP.NET), Drop down List box, JavaScript Array and client side objects like Java Applets.


Prevent Insecure Direct Object References


In simple terms the protection we need is to

- minimize user ability to predict object IDs/Names

- Don’t expose the actual ID/name of objects

- Verify user authorization each time sensitive objects/files/contents are accessed

Use an Indirect Reference Map
Indirect Reference Map may be used to create alternative ID/Name for server side object/data so that exact ID/Name of the object/data is not exposed to the end user. The object ID may be anything like File Name or an internal Customer/User ID (e.g. the Primary key attribute in master tables). Indirect Reference Map maintains a non-sequential & random identifier for a server side resource hence the end user see the alternate ID and not the actual ID of object. This mapping may be temporary stored in server cache or in a permanent mapping table.

For example your application may allow user to download a confidential file from your application. Instead of creating files with obvious names based on org./client ID, you may use randomly generated identifier as file name and maintain a mapping table with user friendly file name. In the client side link you may show the user friendly file name and when resource is requested by user then you may lookup the mapping table for actual (random) file name and allow user to retrieve the file.

Verify User Authorization
Using random/alternate object ID just minimizes the user ability to predict resource identifier that certainly reduce his capability to attack but it does not completely mitigate the attack. If attacker may get knowledge of the alternative object ID (e.g. from browser history on a shared computer) then he send resource request in legitimate manner. Hence it is important to check user’s authorization to confirm that he is a valid user to request this resource. Handling such scenarios with database based validations is much easier to implement in comparison to application code.

For example: You retrieve some critical report contents form Database for a particular customer with below query:

SELECT * FROM FinancialReports WHERE CustomerID=”123?

If the user can manipulate the CustomerID from end user interface then he may pass a different ID to access reports of other customers. You may easily add validation in SQL by checking the user authorization as below:

SELECT * FROM FinancialReports INNER JOIN ReportAccessControlbyOrg On ReportAccessControlbyOrg.OrgId = FinancialReports.OrgId
WHERE CustomerID=”123? AND ReportAccessControlbyOrg.OrgId = “loggedInUser_OrgId”

However if contents are stored outside the Database e.g. File System then you may also need to ensure that other methods of file retrieval are also protected. User may get access by FTP, Path Traversal vulnerabilities, direct HTTP requests to objects.


Continue Reading: OWASP Definition, Threat Agent, Attack Vector and Impact