Let's remember this definition:
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
For some scenarios, this requires the attacker (who happens to be a legitimate user of the site) to know something about the resource to be attacked in order to substitute the expected information (such as their user account) for the victim's information (in this case, another account number, for example).
The canonical example offered by OWASP recreates a scenario in which a query about an account is to be done using a SQL request:
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt =connection.prepareStatement(query , … );
pstmt.setString( 1, request.getParameter("accountNo"));
ResultSet results = pstmt.executeQuery( );The key is in request.GetParameter("accountNo"). An attacker can change this account number for another (once logged in) and try to have access to somebody else's information.
For example, if the account number is sent in the URL, it's possible to recreate this request, including the intended, foreign account:
http://example.com/app/accountInfo?acct=AnotherAccountNo
This is a direct reference to a restricted resource, and the question is: should the user really have access to the AnotherAccountNo parameter included in the request?
Also, it may well happen that the reference is an indirect one. So, the question to answer here, as the OWASP reminds us, would be:
If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?
Note that automated tools don't usually look for these kind of flows just because they are not able to recognize what is to be protected and what is not. This type of vulnerability is quite common, but we find it in applications due to untested coding scenarios.
The recommended prevention approach is to avoid insecure direct object references, protecting object numbers, filenames, and so on.
- Utilization of a per-user or session indirect object reference is recommended. This means, for instance, that a user is now allowed to manually introduce the account number to be requested, but, instead, a description, or even a reference to it.
- This description (or reference) will be resolved at runtime, mapping it to the proper user's account.
- Also, we are reminded that Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
- Solving this in .NET projects is easy using the corresponding procedure before establishing a connection or access to the requested resource.
- For instance, the program can internally store the list or the available resources for a logged user and only allow these resources before any attempt to access them is made
OWASP Enterprise Security API Project (ESAPI) contains more information about how to manage these types of attacks (https://www.owasp.org/index.php/Project_Information:_OWASP_Enterprise_Security_API_Project).
Note
Another official set of guidelines and recommendations are available on Top 10 2007-Insecure Direct Object Reference at https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference.
Note that the user might also base their attack on files, requesting an already known resource file that contains protected information.
Troy Hunt, an MVP developer for Pluralsight, exposes one of these attacks in detail using an ASP.NET application in which the details of a user account are available once the user has logged in (refer to https://www.troyhunt.com/owasp-top-10-for-net-developers-part-4/).
The following screenshot gives us the key to the attack:
As you can see, the key is that using the debugger tools, we can check the format in which the information is sent to the server. In this case, there's a WCF service invoked (CustomerService.svc), and in that service, the GetCustomer method is called, passing it a JavaScript object containing the key of the customer.
Well, that's all the attacker needs. Now, they can change the number with another one and use a tool such as Fiddler to prepare a request that includes the modified information, for example, about another customerId.
One of the flaws, in this case, is that customerId is largely predictable since it's a number. Using a GUID here, as Hunt suggests in his article, is much more secure and doesn't give any extra clue to the attacker (remember that when we saw how to use MongoDB, one of the characteristics was that the ObjectId that MongoDB assigns to each document is, precisely, a GUID).
Of course, the other problem in this sample was that you could send a request by simply adding a request body just as if you were still using the application in an expected manner. I suggest that you read the previously mentioned article if you are interested in the details of this type of attack.