How To Prevent IDOR Attacks

How To Prevent IDOR Attacks

The Insecure Direct Object reference (also known as IDOR) is one of the critical aspects of your website security. This is a consequence of an application directly exposing a specific reference to an object.



The reference could be in the form of a database, user details, files, etc. These files can be accessed without the custody of the authorization. Like we mentioned previously, if the web application was directly accessing the user’s input to catch the user’s details irrespective of the explicit authorization checks, it means the web application is vulnerable to IDOR.




Let’s assume that Crossbar is a social networking website. As we all know, people can create accounts by registering themselves on those websites. They can visualize the settings aspect in which all the sensitive information of the user gets stored, and the sensitive information includes email, phone numbers, etc.



Now, if you try to go to the URL of the website, you see two things. 





The first aspect is /settings, which follows a parameter (UUID) set to a specific numeric value (1336). Now let us focus on this. If we increment the numeric value (1337), things change dramatically. We get to see the sensitive details of ANOTHER user without his/her permission.



We have to see the reasons behind this situation. To understand this, let’s focus on a few more code examples.




As we can see in the PHP code, we are taking the parameter directly and using a ‘to retrieve’ user information. This isn’t the correct way. 




To rectify this issue, the user must have a session cookie (like mentioned above) and then look at the user ID at the backend instead of just taking everything incoming.



Regarding the serverless architecture where the client gives the user ID, the server must ensure security from tampering with the data via the inclusion of a signature JWT or JSON web tokens; both are great examples for this.



Coming back to IDOR, there are some instances in which you can update the values of another user’s account irrespective of the authorization. If we try to do that, we jump into the HTTP requests created in the Burp proxy.





In this parameter, we can see all the numeric values which need to be updated. However, if you look into the UUID parameter, if we change it to 1337, we get a success message.



Now, you cannot ensure that the updated values reflect in the other user’s account. This can also be referred to as the blind IDOR. However, you can eliminate the blind concept by creating another dummy account to test those references. 



Forced Browsing


When the user uploads a file privately, e.g., an image, the web application might expose a direct reference to the file. This is where the threat of website attacker comes into play. If he visits this link, danger alarms ring vigorously. He can see the private image without the user’s permission. 



This is a consequence of the web application unable to map the files to the user’s session. This allows anybody to gain access to your file names and start downloading the private images. 



At times, things may get even more tricky when you find yourself in an IDOR vulnerability; if we tend to go for the delete account request, the backend blindly accepts the user ID from the user and deletes it. 



However, there can be problems in which a user ID is way too complex or puzzling to be enumerated. 






Consider the above as a user UUID. This value is random and can’t be guessed. In these cases, we must find other solutions to leak the user ID. We tend to go for the leakage, but it could not be successful as the UUID is way too long to be rectified. 



However, if we try to go into further details, the UUID was leaked into the JavaScript response where I requested the user’s account. This is called an IDOR vulnerability.



Finding IDORs


Let’s assume that you possess a feature to delete a post. The feature uses a post ID sent from the user and directly deletes the post. However, the server checks if the user has permission to delete the post by requesting a separate service.



We must find whether there is a possible way to bypass this check. Whenever there are multiple services, there could be some differences that how the set of programs or services parse things. This is called a partial differential. 



Furthermore, we should also see how we can make different services see things differently if we pass just one numeric value. What if we send multiple of those values?



We pollute the parameters by adding the same parameter with a different value, referred to as HTTP parameter pollution. This can be used in association with the IDORs. This is precisely how you can stop getting notifications on a single post on Twitter. 




This fundamental objective of the IDOR is to ensure security. In the volatile world today, nothing is secure, not even the websites. As a result, we should try different methodologies to confirm it. One of these is the appropriate utilization of IDORs.



IDORS ensures that the developers are only able to use one user at a time for indirect object references. Going into another account allows the user (in this case, the attacker) to catch all his sensitive information, which could create problems for him going forward. 




Fuzz Testing


The clients must rectify all the errors before delivering the code to the server; for instance, if we go for a social website, it requires an email address and password. Both the names and email addresses should be in a specific format to minimize all the inputs’ vulnerabilities. This is called fuzz testing.



Even though the user executes this procedure on the server, it causes delays. Those delays happen because after the execution, the result is delivered back.



If we go into the context, the validation procedure is commonly done by JavaScript. This results in a quick response to the user without them having to deal with the server. This is an excellent methodology to adopt.



However, problems arise afterward. The developers tend to focus too much on the client-side and completely ignore the drawbacks of the server-side this negligence is very catastrophic for the website.


Model Verification


In the model verification module, you protect the website from a specified parameter tampering where multiple fields are associated with the post parameters to focus on model verification. We dive into an example.




These parameters can be easily converted into an attack by the website attackers. If the attacker has the user’s fingerprints or knows the sensitive information of your account, he can easily access your account without needing your permission. 



If the user is utilizing a WordPress platform, the attacker can easily dive into the source code to figure out all the sensitive details of the user’s account. These are just normal attackers. Things get complicated when the hostile attacker comes into play. 



He will not change the values of the user details. However, he will add another variable in part of the PHP code (boolean) and assign it. 



This allows the attacker to become an admin, which is bad for the developer as the value gets passed into the database.



To prevent this from happening, the developer must not use the view model, which can also be classified as a database entity. The developer must not use unnecessary details for the potential attackers to configure. 



This will minimize the risks of attacks. Furthermore, the necessary details must be verified before their inclusion.