If you are not already familiar with the concept of an Insecure Direct Object Reference, we suggest you review the article entitled “What Is An Insecure Direct Object Reference ?“.
For insight into detecting Insecure Direct Object Reference vulnerabilities within web-applications, please see the article entitled “How To Test For Insecure Direct Object References“.
Strategies For Avoiding Insecure Direct Object References
There are two strategies for avoiding Insecure Direct Object References, each is explained below:
- Logically Validate References
- Use Indirect References
Every web-application should validate all untrusted inputs received with each HTTP Request. At a minimum, the application should perform “whitelist validation” on each input. This means verifying that the incoming value meets the applications expectations for that input, such as:
- Minimum or maximum length
- Minimum or maximum bounds (for numeric values)
- Acceptable characters
- Data Type (e.g. string, date, integer, rational, etc)
- Set membership
- Pattern (phone number, social security, Employer Id etc.)
“Whitelist validation” implies that the application imposes a specific set of checks on each input that must be satisfied, otherwise it it is rejected. Note that Whitelist validation is all about what the input “looks like”, and is unconcerned about what it “means”. Thus, we refer to whitelist validation as Syntactic Validation. As stated above, every untrusted input to the application must be subject to syntactic validation.
It is also possible to augment Syntactic Validation with Logical Validation, by adding checks to see if the given value makes sense. We cannot be specific here, because what “makes sense” depends on the application design and meaning of the input. Some examples will help to clarify:
- The incoming “id” parameter represents a customer identifier, and it must be checked to ensure that the current user is authorized to access it.
- The incoming “account” parameter identifies the user’s account and it must be verified that it IS that users account.
Logical validation can eliminate Insecure Direct Object Reference vulnerabilities by taking into account the semantics of the reference value and ensuring that its values remain within the design intent of the application. Values that fail logical validation should be rejected.
Using Indirect References
An alternate approach to avoiding Direct Object Reference vulnerabilities involves embracing a design approach in which actual references to application-managed resources (such as ids, names, keys, etc.) are replaced with cryptographically strong random values that “map to” the original values. The mapping between the random values and their actual values is maintained on the server, so the application never exposes direct references. This is a more intrusive remediation than mere logical validation, as it impacts the application design.
Notice that due to the randomness of the published values, the use of Indirect References makes it very difficult to maliciously substitute meaningful values for references. Note that there will be a slight performance penalty to be paid for translating between internal and external references. Indirect references is often the preferred approach when a Direct Object Reference is actually sensitive information that should not be exposed, such as a loan number, a social security number, or an account id.
For additional information on Direct Object Reference vulnerabilities, we suggest you consult the OWASP Top 10.
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.