Insecure Direct Object Reference

• 07 February, 2024
• No Comments

IDOR (What and Why)

IDOR a.k.a. Insecure Direct Object Reference is an access control check vulnerability in web applications in which the user can modify or access data objects by manipulating the identifiers (ID) in the web URL or user request sent to the server.

It normally raises when the server lacks to verify whether the user is allowed to access a particular data object. IDOR was popularized when it appeared in OWASP’s top ten web application vulnerabilities in the year 2007.

Here’s a particular example of IDOR.

http://vulnerable-webapp.com/get/userId=2

The web application is said to be vulnerable to IDOR when an existing user or any anonymous user in the application can access other user information by editing the parameters in the URL. It may be by simply guessing another user’s ID.
This was just an example and not necessarily always the case that ID will be in the URL parameter. Most of the time it is in the type of hidden fields in for which is submitted or sometimes even passed through cookies with the request.
Here is an example of the same:

<form action='POST' action='app-code'>
<input type='hidden' value='ID' />
<input type='text' value='db-value-1'/>
<input type='text' value='db-value-2'/>
<button type='submit' value='submit'>
</form>

It might also be the case in some scenarios when users try to access static files on the server-side file system. For example, a user might try to access chat transcripts, images and documents saved in the application’s file system.

Impact of Insecure Direct Object Reference

IDOR are comparatively easy to exploit and find but their impact is catastrophic. It impacts all the three fundamental principal triad of data which are Confidentiality, Integrity, & Availability.
It may lead to unauthorized access to sensitive data, unauthorized modification of data, or even the execution of privileged actions. The extent of the impact depends on the specific implementation and the nature of the data or functionality that can be accessed.

Listed below are a few of its impacts:

• Unauthorized Access
• Modification or Deletion
• Account Takeover
• Financial Loss
• Legal and Compliance Issues

Best Practices for Insecure Direct Object Reference:

IDOR can be mitigated by avoiding direct object references, generating complex global unique identifiers. Though it will not be a full proof solution against IDOR but in combination with proper user access control and user session management will help in mitigating the vulnerability not completely but to a large extent.
Following are a few steps which may be proven effective to prevent IDOR attacks.

• Proper access control and session management.
• Use of complex or difficult to regenerate GUID’s.
• Validate User input.
• Avoid direct object references.

The Challenge:

SecurityBoat conducted CTF challenge in 1st week of February the application was an online store application with common store features and number of products. The primary objective was to capture the hidden flag in the application.

Overview and Initial Analysis of the Challenge:

Most of the rules under the Rules section were same except few changes were there.
After a quick analysis of application we were able to browse different product categories and even add products to cart but to checkout we were required to have a registered user account in the application. Few new features added to application were showing stocks availability and review and rating of product in product details page.
URL for the challenge.

After visiting the challenge URL we will be landing on a webpage showed in following image.

Rules section can be seen as in following image.

After clicking the link we are taken to the rules page with a set of rules regarding the challenge. After going through it we have in depth details of the challenge.

Challenge to find the flag

We are required to register with the application to make purchases and submit reviews and ratings. So, the very 1st step was that we register ourselves in the application from the register page. After successfully registering we will login in registered account to rate and review the products.

The tool which we are using is Burp Suite which I am comfortable with. You can choose your own tool.Before giving review and feedback let us set our proxy and turn our intercept on in Burp Suite. In this way we will be able to know what all parameters are passed. User needs to submit a review message and rating in the form of stars on the scale of 1 to 5.

After submitting review form and intercepting the request in Burp Suite the post request was shown in following screen.

After playing around with parameters we were able to submit reviews on behalf of other users by modifying the user Id and got the Flag with the help of directly referring ID object which was unique in DB. The flag is as shown in screen below.

After revealing the flag and reading the flag it prompted this was one of the flags and there is another flag hidden in the application.

The Quest for the other Flag:

It was easy to identify to find the 1st flag since it was manifested in the new feature which was added for this challenge. After fuzzing with URL, different pages and intercepting different API end points for getting products and adding the same to cart found nothing.
Then in the profile section after inspecting the page source, we found two additional fields which were hidden which were token and username.

The update request intercepted in Burp Suite is as shown in following screen.

But after few trial and error and tampering different parameters came out to be token was required to update the profile. If provided null or removing token profile was not updated throwing error message. A step ahead the token was required to be one of the existing token in application database.

But after a while and providing application generated token we were able update other user details and in the process of doing same got our flag as shown in following screen shot.

Conclusion

So from the above challenge hosted we conclude that IDOR are sometimes easy to identify based on its implementation how the data object identifier plays a role in the application and how important it is that they are exchanged and generated to and from between server and client.
We also came to know how its impacts can be made catastrophic and can affect the 3 triads of data which are Confidentiality, Integrity, and Availability. Lastly we would like to thank SecurityBoat for conducting such CTF challenges which creates cyber-attack awareness in the community. 

For more such challenges

At SecurityBoat, we post various challenges and extend recognition, including rewards and shout outs, to the successful participants of these challenges. To participate in such challenges, follow us on LinkedIn,  Twitter, Facebook and Instagram. 

Our latest blogs and solutions to challenges are available here.

References

• OWASP
• PortSwigger
• IDOR Handbook