IDOR

IDOR

  • At its core, an IDOR is an access control vulnerability in which an application relies on user-supplied input to reference objects directly. In this case, the object could be a picture, a comment on a post, personally identifiable information (PII) associated with a user or even an entire department within an organization.

  • Insecure Direct Object References 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. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more.

  • IDORs can exist throughout the entire application so it is always suggested that if you see IDs then to always test, even if they are guids or some type of "encrypted id". Look for potential leaks of this ID (public profile?) or look for patterns and see if you can generate your own & run it through burp intruder.

Types of IDOR you will see in wild:

  1. The value of a parameter is used directly to retrieve a database record

    http://foo.bar/somepage?invoice=12345
  2. The value of a parameter is used directly to perform an operation in the system

    http://foo.bar/changepassword?user=someuser
  3. The value of a parameter is used directly to retrieve a file system resource

    http://foo.bar/showImage?img=img00011
  4. The value of a parameter is used directly to access application functionality

    http://foo.bar/accessPage?menuitem=12

Testing for IDOR - ( Manual-Method ):

Base Steps:

Testcase - 1: Add IDs to requests that don’t have them

Testcase - 2: Try replacing parameter names

Testcase - 3: Supply multiple values for the same parameter.

Testcase - 4: Try changing the HTTP request method when testing for IDORs

Testcase - 5: Try changing the request’s content type

POST /api/chat/join/123 […] Content-type: application/xml → test

POST /api/chat/join/123 […] Content-type: application/json {“user”: “test”}

Testcase - 6: Try changing the requested file type (Test if Ruby)

Testcase - 7: Does the app ask for non-numeric IDs? Use numeric IDs instead

Testcase - 8: Try using an array

Testcase - 9: Wildcard ID

Testcase - 10: Pay attention to new features

Testing For IDOR - ( Automated Method ):

Finding Broken Access Controlsarrow-up-right

PimpMyBurp #1 - PwnFox + Autorize: The perfect combo to find IDOR - Global Bug Bounty Platformarrow-up-right

Automating BURP to find IDORsarrow-up-right

Reference:

Everything You Need to Know About IDOR (Insecure Direct Object References)arrow-up-right

Finding more IDORs - Tips and Tricks | Aonarrow-up-right

KathanP19/HowToHuntarrow-up-right

Learn about Insecure Object Reference (IDOR) | BugBountyHunter.comarrow-up-right

WSTG - v4.2arrow-up-right

IDOR (Insecure Direct Object Reference)arrow-up-right

What I learnt from reading 220* IDOR bug reports.arrow-up-right

Medium:

Full account takeover worth $1000 Think out of the boxarrow-up-right

All About Getting First Bounty with IDORarrow-up-right

IDOR that allowed me to takeover any users account.arrow-up-right

All About IDOR Attacksarrow-up-right

Access developer tasks list of any of Facebook Application (GraphQL IDOR)arrow-up-right

Tips

Pro tip: Don’t forget to try create/update/delete operations on objects that are publicly readable but shouldn’t be writable. Can you PUT to /api/products and change a price?

Author

KathanP19arrow-up-right

Last updated

Was this helpful?