If you do not already have an understanding of Insecure Direct Object References, we suggest that you review the article entitled “What Is An Insecure Direct Object Reference ?“.
Detecting Insecure Direct Object References
Testing for Insecure Direct Object References is simple in concept, but becomes challenging as the size of the application grows. It boils down to:
A) Identifying request inputs (parameters, headers, etc.) that contain direct references such as identifiers, keys, files, resources, and …
B) Substituting syntactically proper test values in place of the original values. The return of results and/or the failure to generate an error message in response to the substitution is potentially a Direct Object Reference vulnerability. Test values may be standard sentinel malicious payloads (e.g. ../../../../etc/passwd in place of a filename) or random values of the same data type, it depends on the original value and its meaning.
Frankly, once you start looking for them, it is an obvious kind of vulnerability to spot and verify.
Detecting A Direct Object Reference
As an example, suppose that we notice that the following URL is submitted to an application when we click to view a customer’s details:
https://my.domain.com/myApp/getCustomer?id=897
and that the application responds with a page that shows the selected customer data.
In the absence of any other insight into the application, it would be not be unreasonable to suppose that the customer details being requested is identified by the “id” query parameter, and the the value 897 serves as a unique reference to the desired customer.
To determine if the “id” parameter is a Direct Object Reference, we will either capture the request in a web-proxy, or simply copy and paste the URL (if it were to be visible in the browser’s address bar), and re-submit it with a different value for the “id” parameter. We will likely find that the application responds in one of 3 ways:
- The application gracefully handles the input and returns a response that indicates the requested information is not available.
- The application does not gracefully handle the input and return an unhandled exception or a 5XX HTTP Response code indicating an error.
- The application returns customer data corresponding to the value provided in the “id” parameter.
Clearly, the last response provides definitive evidence of a Direct Object Reference vulnerability. Of course, it is not always so simple to find values that return results, even when some do.
This is where automated tools can be indispensable. Security testing tools like Burp Suite and OWASP ZAP make it easy to perform thousands of substitutions on request inputs, and also help you zoom in on results that differ from the rest, and thereby separate the errors from actual results.
When Is A Direct Object Reference A Vulnerability ?
You may be thinking that our example above might just be behaving as the application designers intended, and that would probably be the case if the user is authorized to view the details of any customer. But what if it is possible to access data through a Direct Object Reference that the user would otherwise not be authorized to access or capable of seeing through the client interface ? In this case the Direct Object Reference represents a security vulnerability in the application, and we designate it an Insecure Direct Object Reference. In our example, if the requirements stipulate that salesperson users should only be able to view those customers assigned to them, then our finding would be a vulnerability if we could view another salesperson’s customer data.
For insight into how to avoid or fix Insecure Direct Object Reference vulnerabilities, please read 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.