mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
112 lines
5.3 KiB
Markdown
112 lines
5.3 KiB
Markdown
# IDOR (Insecure Direct Object Reference)
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) appears when a web or API endpoint discloses or accepts a user–controllable identifier that is used **directly** to access an internal object **without verifying that the caller is authorized** to access/modify that object.
|
||
Successful exploitation normally allows horizontal or vertical privilege-escalation such as reading or modifying other users’ data and, in the worst case, full account takeover or mass-data exfiltration.
|
||
|
||
---
|
||
## 1. Identifying Potential IDORs
|
||
|
||
1. Look for **parameters that reference an object**:
|
||
* Path: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000`
|
||
* Query: `?id=42`, `?invoice=2024-00001`
|
||
* Body / JSON: `{"user_id": 321, "order_id": 987}`
|
||
* Headers / Cookies: `X-Client-ID: 4711`
|
||
2. Prefer endpoints that **read or update** data (`GET`, `PUT`, `PATCH`, `DELETE`).
|
||
3. Note when identifiers are **sequential or predictable** – if your ID is `64185742`, then `64185741` probably exists.
|
||
4. Explore hidden or alternate flows (e.g. *"Paradox team members"* link in login pages) that might expose extra APIs.
|
||
5. Use an **authenticated low-privilege session** and change only the ID **keeping the same token/cookie**. The absence of an authorization error is usually a sign of IDOR.
|
||
|
||
### Quick manual tampering (Burp Repeater)
|
||
```
|
||
PUT /api/lead/cem-xhr HTTP/1.1
|
||
Host: www.example.com
|
||
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
|
||
Content-Type: application/json
|
||
|
||
{"lead_id":64185741}
|
||
```
|
||
|
||
### Automated enumeration (Burp Intruder / curl loop)
|
||
```bash
|
||
for id in $(seq 64185742 64185700); do
|
||
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
|
||
-H 'Content-Type: application/json' \
|
||
-H "Cookie: auth=$TOKEN" \
|
||
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
|
||
done
|
||
```
|
||
|
||
---
|
||
|
||
### Error-response oracle for user/file enumeration
|
||
|
||
When a download endpoint accepts both a username and a filename (e.g. `/view.php?username=<u>&file=<f>`), subtle differences in error messages often create an oracle:
|
||
|
||
- Non-existent username → "User not found"
|
||
- Bad filename but valid extension → "File does not exist" (sometimes also lists available files)
|
||
- Bad extension → validation error
|
||
|
||
With any authenticated session, you can fuzz the username parameter while holding a benign filename and filter on the "user not found" string to discover valid users:
|
||
|
||
```bash
|
||
ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
|
||
-b 'PHPSESSID=<session-cookie>' \
|
||
-w /opt/SecLists/Usernames/Names/names.txt \
|
||
-fr 'User not found'
|
||
```
|
||
|
||
Once valid usernames are identified, request specific files directly (e.g., `/view.php?username=amanda&file=privacy.odt`). This pattern commonly leads to unauthorized disclosure of other users’ documents and credential leakage.
|
||
|
||
---
|
||
## 2. Real-World Case Study – McHire Chatbot Platform (2025)
|
||
|
||
During an assessment of the Paradox.ai-powered **McHire** recruitment portal the following IDOR was discovered:
|
||
|
||
* Endpoint: `PUT /api/lead/cem-xhr`
|
||
* Authorization: user session cookie for **any** restaurant test account
|
||
* Body parameter: `{"lead_id": N}` – 8-digit, **sequential** numeric identifier
|
||
|
||
By decreasing `lead_id` the tester retrieved arbitrary applicants’ **full PII** (name, e-mail, phone, address, shift preferences) plus a consumer **JWT** that allowed session hijacking. Enumeration of the range `1 – 64,185,742` exposed roughly **64 million** records.
|
||
|
||
Proof-of-Concept request:
|
||
```bash
|
||
curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
|
||
-H 'Content-Type: application/json' \
|
||
-d '{"lead_id":64185741}'
|
||
```
|
||
|
||
Combined with **default admin credentials** (`123456:123456`) that granted access to the test account, the vulnerability resulted in a critical, company-wide data breach.
|
||
|
||
---
|
||
## 3. Impact of IDOR / BOLA
|
||
* Horizontal escalation – read/update/delete **other users’** data.
|
||
* Vertical escalation – low privileged user gains admin-only functionality.
|
||
* Mass-data breach if identifiers are sequential (e.g., applicant IDs, invoices).
|
||
* Account takeover by stealing tokens or resetting passwords of other users.
|
||
|
||
---
|
||
## 4. Mitigations & Best Practices
|
||
1. **Enforce object-level authorization** on every request (`user_id == session.user`).
|
||
2. Prefer **indirect, unguessable identifiers** (UUIDv4, ULID) instead of auto-increment IDs.
|
||
3. Perform authorization **server-side**, never rely on hidden form fields or UI controls.
|
||
4. Implement **RBAC / ABAC** checks in a central middleware.
|
||
5. Add **rate-limiting & logging** to detect enumeration of IDs.
|
||
6. Security test every new endpoint (unit, integration, and DAST).
|
||
|
||
---
|
||
## 5. Tooling
|
||
* **BurpSuite extensions**: Authorize, Auto Repeater, Turbo Intruder.
|
||
* **OWASP ZAP**: Auth Matrix, Forced Browse.
|
||
* **Github projects**: `bwapp-idor-scanner`, `Blindy` (bulk IDOR hunting).
|
||
|
||
|
||
|
||
## References
|
||
* [McHire Chatbot Platform: Default Credentials and IDOR Expose 64M Applicants’ PII](https://ian.sh/mcdonalds)
|
||
* [OWASP Top 10 – Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
|
||
* [How to Find More IDORs – Vickie Li](https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489)
|
||
* [HTB Nocturnal: IDOR oracle → file theft](https://0xdf.gitlab.io/2025/08/16/htb-nocturnal.html)
|
||
{{#include ../banners/hacktricks-training.md}}
|