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

Overview of IDOR

• What is an Indirect Object Reference (IDOR)?

• How does IDOR occur?

• Examples of IDOR.

• Recent real-life case study

• Practical demonstration.

• Prevention.

What is IDOR or Insecure direct 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.