ContextQMD
Back to Payloadsallthethings

Insecure Direct Object References

Insecure Direct Object References/README.md

4.27.3 KB
Original Source

Insecure Direct Object References

Insecure Direct Object References (IDOR) is a security vulnerability that occurs when an application allows users to directly access or modify objects (such as files, database records, or URLs) based on user-supplied input, without sufficient access controls. This means that if a user changes a parameter value (like an ID) in a URL or API request, they might be able to access or manipulate data that they aren’t authorized to see or modify.

Summary

Tools

Methodology

IDOR stands for Insecure Direct Object Reference. It's a type of security vulnerability that arises when an application provides direct access to objects based on user-supplied input. As a result, attackers can bypass authorization and access resources in the system directly, potentially leading to unauthorized information disclosure, modification, or deletion.

Example of IDOR:

Imagine a web application that allows users to view their profile by clicking a link https://example.com/profile?user_id=123:

php
<?php
    $user_id = $_GET['user_id'];
    $user_info = get_user_info($user_id);
    ...

Here, user_id=123 is a direct reference to a specific user's profile. If the application doesn't properly check that the logged-in user has the right to view the profile associated with user_id=123, an attacker could simply change the user_id parameter to view other users' profiles:

ps1
https://example.com/profile?user_id=124

Numeric Value Parameter

Increment and decrement these values to access sensitive information.

  • Decimal value: 287789, 287790, 287791, ...
  • Hexadecimal: 0x4642d, 0x4642e, 0x4642f, ...
  • Unix epoch timestamp: 1695574808, 1695575098, ...

Examples:

Common Identifiers Parameter

Some identifiers can be guessed like names and emails, they might grant you access to customer data.

  • Name: john, doe, john.doe, ...
  • Email: [email protected]
  • Base64 encoded value: am9obi5kb2VAbWFpbC5jb20=

Examples:

Weak Pseudo Random Number Generator

  • UUID/GUID v1 can be predicted if you know the time they were created: 95f6e264-bb00-11ec-8833-00155d01ef00
  • MongoDB Object Ids are generated in a predictable manner: 5ae9b90a2c144b9def01ec37
    • a 4-byte value representing the seconds since the Unix epoch
    • a 3-byte machine identifier
    • a 2-byte process id
    • a 3-byte counter, starting with a random value

Examples:

Hashed Parameter

Sometimes we see websites using hashed values to generate a random user id or token, like sha1(username), md5(email), ...

  • MD5: 098f6bcd4621d373cade4e832627b4f6
  • SHA1: a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
  • SHA2: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

Examples:

Wildcard Parameter

Send a wildcard (*, %, ., _) instead of an ID, some backend might respond with the data of all the users.

  • GET /api/users/* HTTP/1.1
  • GET /api/users/% HTTP/1.1
  • GET /api/users/_ HTTP/1.1
  • GET /api/users/. HTTP/1.1

IDOR Tips

  • Change the HTTP request: POST → PUT
  • Change the content type: XML → JSON
  • Transform numerical values to arrays: {"id":19} → {"id":[19]}
  • Use Parameter Pollution: user_id=hacker_id&user_id=victim_id

Labs

References