maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
hacktricks/src/pentesting-web/idor.md

8.0 KiB
Raw Blame History

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

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

Коли 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", щоб виявити валідних користувачів:

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:

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

Посилання