A “Direct Object Reference” describes a web-application design approach in which real keys or entity names are used to identify application-controlled resources and are passed in URLs or request parameters. A Direct Object Reference represents a vulnerability (i.e. an Insecure Direct Object Reference) if it is possible to substitute a different value for the key or name and thereby access a different resource through the application that is inconsistent with the designer’s intentions and/or for which the user is not authorized.
Insecure Direct Object Reference Example 1
Consider a web-application that requires authentication, and once authenticated, presents the user with a list of their investment portfolios for review and editing. Let us further assume that when the user chooses to view a portfolio, their submission (i.e. request) passes the target portfolio identifier as a URL query parameter value. The (server-side) application verifies previous authentication, and then uses the portfolio identifier to retrieve the relevant portfolio data and display it to the user.
This is a common design approach that in itself is not problematic. However, a vulnerability emerges as our scenario continues. Let’s imagine that we copy the URL that was submitted when the user requested to view a portfolio, and we change the “portfolioId” in the URL to a value that does not correspond to a portfolio owned by the user and to which they should not have access. If, when we submit the modified URL, the application responds with the details of the specified portfolio, we have an Insecure Direct Object Reference vulnerability on our hands because it is possible to view data to which the user is not entitled simply by requesting it through a particular parameter.
Insecure Direct Object Reference Example 2
As a second example, consider an application that allows the user to export their data to a spreadsheet and download it. When the user chooses to export their data, the application creates a file, and the client browser is redirected to the exported file by name. Careful observation shows us that the filename used to store the exported data is the user id followed by a integer, suggesting a counter.
Once again, if we were to copy and modify the specific request that downloads the file, we might change the filename to reflect a different user id and see if we can download a file. Perhaps we would need to submit many URLs until we find another user’s export file, but if we were eventually successful, it would clearly be an Insecure Direct Object Reference vulnerability.
Even worse, we might try replacing the original file name value with any arbitrary file path, to see if their are any restrictions on the download. (See “What Is Path Traversal ?“)
Keys, Files, URLs
Clearly, any direct references to resources accessible by the application that are passed as inputs are potential Insecure Direct Object Reference vulnerabilities. This includes values such as database keys, file names, file paths, and Universal Resource Locators (URLs). In fact, Insecure Direct Object References is a category of web-application vulnerabilities that includes Path Traversal, Open Redirect, and others.
For insights into how you would detect Direct Object Reference vulnerabilities, please see the article entitled “How To Test For Insecure Direct Object References“.
For insights into how to avoid or fix Insecure Direct Object References, please see the article entitled “How To Prevent Insecure Direct Object References“.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.