Authorization / Permissions: IDOR

Best Practices for IDOR Reporting

This article should be used as a guide for Access / Privacy Control Violation submissions. Some general template information is given and may be used, but due to the nature of this category, very specific information may need to be included in your report to fully meet all requirements. We realize that not ALL vulnerability reports will be able to follow this guide.

Overview:

Insecure Direct Object Reference (IDOR) occurs when an application exposes a reference to an internal implementation object. This reveals the identifier and format/pattern used of the object in the storage, backend side.

Declaring attacker(s) and victim(s) in your report:

• Attacker: role + credentials (example: Read-only User + ROU : P@ssW0rd)

• Victim: role + credentials (example: Admin User + ADM : P@ssW0rd)

• Anonymous access to protected endpoints

Discovery:

An adequate description includes:

• Describe why is this an IDOR. (how are you determining the attacker shouldn't be accessing the victim's objects?)

• Include enough information for the reader to understand what the steps will demonstrate. (please do this without including specific steps or details; these should ONLY be in the steps)

---

Template Contents

---

Title

IDOR on {insert unique location here/state "multiple locations"} on {param} - CRUD: {(C)reate/(R)ead/(U)pdate/(D)elete}

---

Description

{add an adequate description following the above guidelines (attacker/victim declaration & discovery)}

During the testing of {application/host/endpoint}, an access control issue was discovered that affects {users/roles} on {endpoint(s)/functionality}.

As described by OWASP: Insecure Direct Object References (IDOR) 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.

NOTE TO SRT: Please avoid using portions of your steps in the Description. This section should be generic in nature. In the Validation Steps section you can reiterate things you point out in the Description. For example: "Step 5: Visit Y as the lower role. As you can see user X is accessing admin's dashboard and can see all the admin view data.”. We will reject any report if the Description is inadequate. IDORs are a large time investment, and we need to understand what you are demonstrating before any further investigation.

---

Impact

General impact as described by OWASP: 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.

For this specific {application/host/endpoint} the following impact is:

• {List impact here}

---

Recommended Fix

From OWASP:

Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):

• Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.

• Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.

---

---