A1:2021 | Insecure Direct Object Reference (1) | Cycubix Docs
Direct Object References are when an application uses client-provided input to access data & objects.
Insecure Direct Object References (IDOR) indicate a vulnerability that occurs when an application provides direct access to objects based on user-supplied input, and it doesn't verify the user's authorization to access those objects.
These are considered insecure when the reference is not properly handled and allows for authorization bypasses or disclose private data that could be used to perform operations or access data that the user should not be able to perform or access. Let’s say that as a user, you go to view your profile and the URL looks something like:
Some Examples
Examples of Direct Object References (DOR) using the GET method can include URLs where parameters directly reference objects such as files, database records, or other resources. Here are some scenarios that illustrate this concept:
Example 1: User Profile Access
A web application allows users to view their profile information by specifying their user ID in the URL.
If an attacker changes the id parameter to another user's ID, such as id=12346, and the application does not verify the user's authorization, the attacker might access someone else's profile information.
Example 2: Document Access
An application allows users to download documents by specifying the document ID in the URL.
If the application does not perform proper access checks, an attacker could change the documentId to access restricted documents.
Example 3: Order Details
An e-commerce site lets users view their order details by passing an order ID in the URL.
If the application does not verify that the order belongs to the logged-in user, an attacker could modify the orderId to view other users' orders.
Example 4: File Access
A web application allows users to view files by specifying the file name in the URL.
If the application does not restrict access to certain files, an attacker could change the file parameter to access sensitive files.
Other Methods
POST, PUT, DELETE or other methods are also potentially susceptible and mainly only differ in the method and the potential payload.
More good reading
Before we go on to practice, here’s some good reading on Insecure Direct Object References:
OWASP cheatsheet on IDOR visit: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
Last updated