Recently apptroops found one weak spot in the Top US Travel website where the attacker could see the personal information of all the users. Have you ever noticed a parameter in a URL and tried tweaking it to retrieve a different valid page/request? If you are successful, you exploit an insecure direct object reference.
Description
Insecure Direct Object References have occupied the fourth spot of the OWASP Top 10 list of the most critical web application security risks since 2007.
Insecure Direct Object References occur when an application provides direct access to objects based on the user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.
Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user-supplied input and uses it to retrieve an object without performing sufficient authorization checks.
What was the Risk?
The website was using some token to authenticate users but token was not validating properly which opened the window for the attacker to perform insecure direct object reference attack. Changing the values of users (user_id) in increasing or decreasing the number, the attacker could see the personal information of all the users on the website. Such flaws can compromise all the data that can be referenced by the parameter.
Mitigation or Fix
Preventing insecure direct object references requires selecting an approach for protecting each user-accessible object:
Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources.
Check access. Each use of a direct object reference from an un-trusted source must include an access control check to ensure the user is authorized for the requested object.
Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
