Products

Solutions

Resources

Search for API Security Tests

The IDOR Blueprint: A Comprehensive Guide to Identifying and Mitigating Vulnerabilities

IDOR is a type of security vulnerability that is caused by an application's failure to properly validate and authorize user input leading to unauthorized action.

Author Image

Medusa

8 mins

A company that suffered a major data breach in 2016 due to an Insecure Direct Object Reference (IDOR) vulnerability is Uber, a ride-sharing app. The breach exposed the personal information of over 57 million users, including names, email addresses, and phone numbers. It was reported that the hackers were able to access a private GitHub repository used by Uber engineers, where they found login credentials for an Amazon Web Services (AWS) account. Using these credentials, the hackers were able to access and download user data stored on AWS. The breach dealt a major blow to Uber's reputation and resulted in a $148 million settlement with all 50 US states and the District of Columbia

This blog covers:

  • What is an Indirect Object Reference (IDOR)?

  • How does IDOR occur?

  • Examples of IDOR.

  • Recent real-life case study

  • Practical demonstration.

  • Prevention.

What is Indirect Object Reference?

IDOR, or Insecure Direct Object Reference, is a type of security vulnerability that is caused by an application's failure to properly validate and authorize user input. Essentially, this occurs when an application trusts user input to determine which objects or resources to retrieve or manipulate, without verifying that the user is authorized to access those objects or resources. As a result, attackers can access sensitive data or confidential information that they should not have access to, and can even modify or delete that data.

This type of vulnerability can have serious consequences, including data breaches, loss of intellectual property, financial loss, and reputational damage. Attackers can exploit IDOR vulnerabilities to gain access to confidential information such as personal data, financial records, and trade secrets. Additionally, IDOR attacks can be difficult to detect, since they often look like legitimate user actions.

How IDOR Occurs?

IDOR occurs when an application relies on unvalidated user input to identify objects in the system. For example, imagine a web application that allows users to view their own account information by entering their user ID. If the application simply uses this user ID to query the database without checking whether the user is authorized to view that information, an attacker could easily manipulate the user ID to view other users' information.

Example HTTP Requests and Responses of IDOR

Consider the following HTTP request that is used to retrieve a user's account information:

GET /api/user/{user_id}/account HTTP/1.1 
Host: example.com 
Authorization: Bearer {access_token}

In this request, the {user_id} parameter is used to identify the user whose account information is being requested. An attacker could manipulate this parameter to access other users' account information by simply changing the value of {user_id} in the request.

If the application is vulnerable to IDOR, the server would respond with the requested user's account information, even if the attacker is not authorized to view it.

Vulnerable code

Consider the following backend source code, which retrieves a user's account information based on the user ID parameter passed in the request:

@app.route('/api/user/<user_id>/account', methods=['GET']) 
def get_user_account(user_id): 
  account = db.query("SELECT * FROM accounts WHERE user_id = %s", user_id) 
  return jsonify(account)

In this code, the user_id parameter is used directly in the SQL query without any validation or authorization checks. An attacker could easily manipulate the user_id parameter in the request to access other users' account information.

Here's another example of a vulnerable endpoint:

GET /api/orders/<order_id> HTTP/1.1 
Host: example.com 
Authorization: Bearer {access_token}

This endpoint retrieves the details of an order based on its order_id. If the application is vulnerable to IDOR, an attacker could manipulate the order_id parameter in the request to access other users' order information.

Another Example

Consider the following HTTP request that is used to submit feedback about a product in JSON format:

POST /api/products/feedback HTTP/1.1 
Host: example.com 
Content-Type: application/json 
Authorization: Bearer {access_token} 
{ 
  "product_id": 123,
  "message": "This product is great!" 
}

In this request, the product_id parameter is used to identify the product for which feedback is being submitted. An attacker could manipulate this parameter to submit feedback for other products by simply changing the value of product_id in the request.

If the application is vulnerable to IDOR, the server would accept the feedback for the requested product, even if the attacker is not authorized to submit feedback for it.

Vulnerable code

Consider the following backend source code, which submits feedback for a product based on the product_id and message parameters passed in the JSON body of the request:

@app.route('/api/products/feedback', methods=['POST']) 
def submit_feedback(): 
  data = request.get_json() 
  product_id = data.get('product_id') 
  message = data.get('message') 
  db.query("INSERT INTO feedback (product_id, message) VALUES (%s, %s)", product_id, message) 
  return jsonify({'message': 'Feedback submitted successfully!'})

In this code, the product_id parameter is used directly in the SQL query without any validation or authorization checks. An attacker could easily manipulate the product_id parameter in the request to submit feedback for other products.

If you want to see a live practical demonstration, check this out!


Recent real-life case study

A security vulnerability has been discovered in Microsoft Teams that could potentially allow attackers to send malware. This vulnerability is commonly known as an IDOR vulnerability. Essentially, this means that malicious files can be delivered from external sources without proper authorization checks.

This could be a significant risk to organizations that use Microsoft Teams frequently. Attackers could potentially gain access to confidential information such as personal data, financial records, and trade secrets. Additionally, IDOR attacks can be difficult to detect as they often look like legitimate user actions.

For more information on the exploitation of this vulnerability, read this.

Test for IDOR using the best proactive API Security product

Our customers love us for our proactive approach and world class API Security test templates. Try Akto's test library yourself in your testing playground. Play with the default test or add your own.

Practical Demonstration

Target Application: OWASP Juice Shop

OWASP Juice Shop has a functionality that allows users to add a review for a particular product.

For example, I am going to add "perfecto" as my review and click on submit.

Here, we can see other users' reviews along with ours. After submitting a review, you can edit it as well.

Exploring Endpoints

Above, we saw how the functionality normally works. Now, I will check what requests are being generated behind the scenes in BurpSuite.

The endpoint highlighted with the PATCH HTTP method is generated when a review is edited.

Target API Endpoint: /rest/products/reviews

We can see that this endpoint requires an ID and a message as inputs to submit feedback. The ID is randomly generated and cannot be guessed. Does this mean there is no Insecure Direct Object Reference (IDOR) vulnerability? Not necessarily. Let's explore this further.

There is another endpoint that fetches all the reviews for a specific product. A number in the endpoint path indicates the product.

Target Endpoint: /rest/products/1/reviews

This endpoint is fetching all the reviews for product number 1.

Another interesting point to note is that the response contains the IDs of the users who have submitted a review. In a normal scenario, we shouldn't be able to see these IDs since they are used to identify a particular user. This is actually a case of information disclosure.

Exploitation

Knowing the IDs of another user and the admin, we can try to submit a review on behalf of the other user by changing the ID in the request of the previous endpoint.

Vulnerable Endpoint: /rest/products/reviews

Change the id value to the admin’s id we found earlier and send the request.

Here, we can see that the initial message from the admin, "One of my favorites!", has been updated to "perfecto!". We achieved this by changing someone else's review through the JSON body of the request.

We were able to change someone else's review by swapping IDs in the request JSON body because the application relied on unvalidated user input to identify objects in the system, which is the basic mechanism of an IDOR vulnerability. In this case, we were able to manipulate the ID parameter in the request. The server responded with the requested user's review, even if the attacker was not authorized to modify it.

Here are some real-life IDOR attacks you can check out:

how-idor-caused-exposure-of-floridas-tax-filers-data

idor-vulnerability-found-in-microsoft-teams-product

Prevention Measures

The following are some best practices for preventing IDOR vulnerabilities:

  • Implement Access Controls: Implement access controls to ensure that users can only access the data and resources that they are authorized to access. This can include role-based access controls, permission-based access controls, and other types of access controls.

  • Validate User Input: Always validate user input to ensure that it is safe and appropriate for the intended use. This can include input validation, data sanitization, and other types of input validation.

  • Use Indirect References: Use cryptographically strong random values to replace resources such as IDs, names, and keys. The original values and the random values are both stored on the server, so there is no direct reference to be exposed. This complicates the attack methodology beyond logical validation, making it more difficult for hackers to substitute meaningful values for references.

  • Use Non-enumerable Identifiers: Use non-enumerable identifiers to prevent attackers from manipulating object IDs. Do not use sequential numbers or IDs that are easily guessable. Instead, use randomly generated IDs or hashes that are difficult to guess or predict. This can make it much more difficult for attackers to exploit IDOR vulnerabilities in your application.

  • Internal microservices: Access control checks should be present on internal microservices too. Even if the internal service isn’t accessible from the public network.

In conclusion, IDOR vulnerabilities can have serious consequences for organizations and users alike. It is important for developers to understand how IDOR occurs and to implement best practices for preventing these types of vulnerabilities. By implementing access controls, validating user input, using object references, implementing monitoring and alerting, and conducting regular security audits, organizations can significantly reduce their risk of IDOR-related data breaches and other security incidents.

Thank you for being a part of this blog. Keep exploring and revolutionizing the web!

Share this post

Share this post

Share this post

Monthly product updates in your inbox. No spam.

Table of contents