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.
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.