An Insecure Direct Object Reference vulnerability occurs when data in an application is exposed without appropriate checks being made before the access is granted. The data could include files, personal information, data sets, or any other information that a web application has access to.
A simple example could be as follows. A web application is using an alphanumeric code in a URL to provide an authorised user access to a set of data. For example:
This looks pretty innocuous. But what if the parameter a=23tfs194583 is a reference number linked to a set of records in the web application data store? Could a similar alphanumeric sequence also be a reference to a different set of data? If the user of the web application changed the URL so that the parameter was slightly different, say changed the last 3 to a 2 like this:
and the parameter a=23tfs194582 is a valid reference number, would it display data to the user that they shouldn’t see? This is an Insecure Direct Object Reference. If authorised users of a web application can see reference parameters such as this, and can change them in URLs or any other place in the application, then there is a potential for data to be exposed to people who shouldn’t see it. This is especially true if the web application security model places too much trust on the initial authentication of users.
Not all Insecure Direct Object Reference vulnerabilities show up as parameters on screen. It’s possible for reference data to be returned from a web application in data that is under the hood. For example, JSON or XML data could be returned but not displayed. Users with knowledge of parsing JSON or XML files could inspect these, or use a tool to do it, and get access to data that could allow them to construct a request for data they are not meant to see.
How to protect against Insecure Direct Object Reference vulnerabilities
This type of vulnerability actually highlights two types of security flaw. Firstly, it’s a bad idea to display direct object references to users. It’s very unlikely they need to know them to use an application and doing so just creates a risk. Not just due to the scenario outlined above were the user changes the reference themselves. Displaying references also opens them up to being copied by people who see them on screen. The second type of security flaw that is highlighted here is related to the word insecure in the vulnerability name. Allowing access to data without doing an authorisation check at the time of access is a wide open door to data loss. It should never be assumed that an authenticated user of a web application has the rights to access any data that is requested during their session. All requests for data should be checked against permissions and access control lists for the data in question each time an access request is made.
If an application needs to use some form of reference to provide access to data, then these should be obfuscated so their is no discernible pattern to them. They should also be randomised if possible so that the same reference can’t be reused to get access to the data set. It should be emphasised that obfuscation should not be seen as a substitute for a secure access control mechanism to data. Implement proper access controls to data first and then layer obfuscation over that underlying security procedure.
As stated in other articles covering the OWASP Top 10 it’s vital that systems are kept up to date with the latest software versions. Security vulnerabilities and bugs are constantly being discovered and fixed. General network security infrastructure should be kept up to date as well. Firewalls, content checkers, anti-malware systems and Load Balancers should be running the latest software patches. Additional security tools should also be deployed and kept up to date. The KEMP Web Application Firewall Pack (AFP) for LoadMaster includes tools that continuously monitor traffic to application and web servers. It detects and counters known vulnerabilities, including those outlined by OWASP. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities developers and system administrators may not have heard about are countered.