How I found IDOR in a Travel Agency Application

Hello guys, I hope you are all doing well. I spent hours and days finding a critical vulnerability: an Indirect Object Reference (IDOR). I'm excited to share how I found it and how it can lead to Account Takeover. I hope you will find something useful and enjoy the content.

Methodologies to find IDOR:

While testing for IDOR, I look manually and use tools to find the user endpoints. Here is my approach to test IDOR vulnerability:

• Get the HTTP request into Burp after login session
• In Burp Suite, there is an extension called Authorize; this tool helps to find missing access controls
• Once access control is validated with object references like user_id,token_id, invoice_id, we assess IDORs here

I'll upload one more blog how to chain IDOR with Full Account Take Over and few evasion techniques by high severities.

Testing Features:

While testing this application, I checked every header to change the operations. For example, if user information is validated with the user_id parameter on the client side, by manipulating the parameter for CRUD operations;

• Create- Creating a new user id whether it is guessable or not guessable, will try to change the parameter with an encoding format.
• Read- Can I able to read other user's by changing the parameter
• Update- Can I able to modify the user id value with an existing user id
• Delete- Check user able to delete another user without authorisation.

Let's see the attack surface in our target application:

Once I registered, then send login request to Burp for application validation whether a header or parameter is validated on the server side. For example _token parameter, which is nothing but a CSRF token.

Short brief on CSRF vulnerability: Cross-Site Request Forgery a web security vulnerability that tricks an authenticated user into performing unauthorized, state-changing actions on a web application without their knowledge.

For the CSRF vulnerability above, I'll write a separate blog on how to identify the CSRF token and forge it.

In this application, I can see the email parameter as well as the user_id parameter. Changing user_id alone is not vulnerable to IDOR; this happens with email manipulation, symmetric key encryption tokens, access control, and low-privileged user-to-high-privileged user roles.

Here, this application is validating with user_id, but it misses email validation, where I can able to change an existing user's email; this allows unauthenticated email verification, leading to IDOR.

Now the browser blindly trusts an unauthenticated user to change new mail id.

Updating the new email ID leads to improper user account verification, which escalates to an IDOR vulnerability.

Mitigation:

Changing the email id to unauthenticated user leads to ATO. How to mitigate this vulnerability?

1. Validate the email ID parameter with user_id
2. Server-side validation should be authenticated with an authorization bearer token.
3. Make sure not to use guessable user_id and plain text format; it should be hashed with AES encryption.
4. Implement rate-limiting and a weak lockout session.

Thank you, Tech Buddies

Happy Hacking!

Eat, Hack, Gym, Sleep

This is Jaga, Signing off