Hello people, hope you are doing good and playing well with security!

Today I am here again with a topic known as Insecure Direct Object References (IDOR), I got this vulnerability while doing a VAPT(Vulnerability Assessment & Penetration Testing) for a client.

What is it?

According to wiki
“Insecure Direct Object References(IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.”
In simple words, it’s like

“Getting sensitive information by just changing a few values in the parameter“

How an IDOR(Insecure Direct Object References) works?

Here In the above Fig. you can see that an attacker is requesting the server to get his profile information with user id “101” in return, he gets his profile information from the server now he tries to manipulate the user id value to “103” and still he is getting a 200 ok response. It means the server is not doing a proper verification for the user’s requests. It’s just passing the response for any value. Thus this is IDOR.

Now coming to the topic, Is the IDOR just for that? Try going a bit deeper inside the application.

Suppose if we get the HTTP methods enabled with this IDOR What all a hacker can do here? Think about it!

Here is the sample request that shows IDOR vulnerability,

Here if we change the user id to something else we are getting any other user’s profile information & there’s a lot of critical information here, Now after this, we can stop here and directly report it or well try to get a bit deep inside it. Can you see the HTTP methods enabled in the response field?

What are HTTP methods and what are they used for?

HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. In simple words, we can say,

“It’s a way for connection between the server and the user”

There are total of 9 HTTP methods, they are

GET:- The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
HEAD:- The HEAD method asks for a response identical to that of a GET request, but without the response body.
POST:- The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.
PUT:- The PUT method replaces all current representations of the target resource with the request payload.
DELETE:- The DELETE method deletes the specified resource.
CONNECT:- The CONNECT method establishes a tunnel to the server identified by the target resource.
OPTIONS:- The OPTIONS method is used to describe the communication options for the target resource.
TRACE:- The TRACE method performs a message loop-back test along the path to the target resource.
PATCH:- The PATCH method is used to apply partial modifications to a resource.

Now Coming to the topic, In the above request if we change the HTTP method from GET to DELETE, will it delete the user from the database?

Yeah, it’s working, we are able to delete the customer just by changing the request method.

Now if we are able to fetch information by GET and erase the information by DELETE, then why not give a try to PUT method.

Here if we use the PUT method, we are able to edit/change the customer’s information, like first name, last name, dob…etc, or it can be anything, so how can it lead to full account takeover

There are two ways we can do that,
1) Using the PUT method change the password
2) Using the PUT method change the email and contact no

Once we change the email and contact no. We can request a new password from the reset password page and then just change the password.

Thus this leads us to a single account takeover. How can we take down the whole company then?

The answer is BRUTE-FORCE the user id field with the PUT method.

Thus we need to do a brute force attack by adding the email field in the request and use intruder to brute force it. Within a few hours, the company will be down none of the user’s will be able to relogin.

Thus in this way, we could take down a whole company by
Insecure Direct Object References(IDOR).

What will be the mitigation for the IDOR?

1) Avoid Exposing Direct Object References :-

In this try to avoid exposing the direct object references like “www.xyz.com/user/23456” instead try configuring in this way “www.xyz.com/myprofile“ and use the information already present in the user’s session on the server to locate the resources to serve.

2) Check User Access at the Data-Object Level :-

Add proper Authorization while implementing the server-side access controls, it is relatively obvious to add authorization checks at the functionality or route level. A common issue that causes this vulnerability is missing access checks at the data or object level to protect against tampered IDs in URL parameters. You need to enforce the data layer access controls by verifying that the current user owns or is allowed to access the requested data.

Thus this was all about today’s topic, Hope you like it, Subscribe to my blog for further updates on security.

Hint for the next blog:- Bug bounty can be done in 2 ways hard work and smart work which one you prefer?
…. To be continued

Till then Happy hacking!