root Insecure Direct Object References (IDOR): Повний гайд, реальні кейси, технічний аналіз та методи захисту
IDOR (Insecure Direct Object References) — одна з найпоширеніших і найнебезпечніших веб-уразливостей.
Вона виникає тоді, коли застосунок дозволяє користувачу отримати доступ до об’єктів (файлів, акаунтів, записів у БД, номерів замовлень, документів), просто змінивши ID у запиті.
Якщо сервер не перевіряє права доступу — атакувальник може побачити або змінити дані інших користувачів.
IDOR протягом багатьох років входить у список OWASP Top 10, оскільки часто призводить до витоку персональних даних, зламу акаунтів, маніпуляцій платежами та повного компрометування системи.
1. Що таке IDOR?
IDOR виникає тоді, коли застосунок дозволяє користувачу напряму звертатися до ресурсів через ідентифікатори:
- номери користувачів (
user_id=123) - номери документів (
file=invoice_554.pdf) - записи в БД (
order_id=9910) - імена файлів (
download.php?file=report45.xls) - ключі у JSON (
"document": 55)
Сервер має перевіряти, чи має користувач право на доступ до конкретного ресурсу.
Якщо перевірки немає — це і є IDOR.
2. Простий приклад IDOR
Запит користувача:
GET /api/profile?user_id=105
Якщо змінити ID:
GET /api/profile?user_id=106
і побачити інший профіль — уразливість присутня.
Те ж саме стосується завантаження документів:
GET /api/download?file=invoice_105.pdf
Атакувальник просто перебирає інші файли:
invoice_106.pdf
invoice_107.pdf
invoice_108.pdf
3. Більш складні сценарії IDOR
IDOR виникає не лише в URL, а й у:
- POST-запитах
- JSON-тілах
- GraphQL
- вебхуках
- мобільних застосунках
- desktop-клієнтах
- завантаженні файлів (file ID)
Приклад POST-IDOR:
POST /api/update-profile
{
"user_id": 331,
"email": "new@mail.com"
}
Атакувальник міняє "user_id" і змінює дані іншого акаунта.
4. Реальні кейси IDOR з компаній (Facebook, PayPal, Uber)
4.1. Facebook (Meta) — доступ до особистих фото
Дослідники знаходили IDOR у запитах виду:
GET /photos/view?photo_id=...
Змінивши ID, можна було переглядати приватні фото інших людей.
4.2. Uber — зміна даних водіїв
API дозволяло змінювати параметри профілю водія, просто замінивши ID. Через це можна було:
- змінювати номери авто
- змінювати банківські реквізити
- вимикати акаунт водія
4.3. PayPal — доступ до транзакцій інших людей
У старому API транзакції були доступні за transaction_id, і сервер не перевіряв, кому вони належать. Це дозволяло масово переглядати чужі платежі.
4.4. Instagram — IDOR у /friendships/
Дослідник міг керувати відносинами (follow/unfollow) від імені будь-якого користувача, змінивши user_id.
5. Типові об’єкти, які можна зламати через IDOR
- акаунти користувачів — профілі, email, телефони
- замовлення — історія операцій, чеки
- документи — PDF, договори, рахунки
- платіжні деталі — IBAN, карточні токени
- чати — приватні переписки
- файли — фото, архіви, конфіденційні звіти
- підписки — зміна тарифів
- адмінські панелі — отримання прав модератора
6. IDOR у API та мобільних застосунках
6.1. API — найчастіше місце появи
Особливо у:
- REST API
- GraphQL
- microservices
- внутрішніх адмінських API
Приклад уразливого API:
GET /api/v3/orders/5541
Атакувальник змінює:
orders/5542
orders/5543
orders/5544
та бачить чужі замовлення.
6.2. IDOR у мобільних застосунках
Багато мобільних клієнтів кешують ID у JSON-параметрах.
Користувач може швидко змінювати їх через Burp Suite.
7. Broken Object Level Authorization (BOLA) vs IDOR
BOLA — ширше поняття, яке включає IDOR.
В API-безпеці IDOR тепер найчастіше називають саме BOLA.
Формально:
- IDOR — відсутність перевірки доступу до об’єкта
- BOLA — будь-яка логіка неправильного контролю доступу на рівні об’єктів
У 90% випадків IDOR = BOLA.
8. Як знайти IDOR при тестуванні?
Методи пошуку IDOR:
8.1. Зміна ID у запитах
- інкремент (
123 → 124 → 125) - декремент (
123 → 122 → 121) - вставка чужих ID
8.2. Заміна на великі/малі числа
9999999999
1
0
-1
8.3. Заміна на UUID або інші типи
Якщо система очікує UUID, але приймає цифрові ID — майже гарантований IDOR.
8.4. Масове тестування (Burp Intruder, Turbo Intruder)
Можна перебирати сотні ID і дивитися різницю у відповідях.
9. Наслідки IDOR
IDOR часто призводить до:
- повного зламу акаунтів
- масового витоку персональних даних
- розкриття фінансової інформації
- підробки переказів
- скасування або зміни чужих замовлень
- миттєвої компрометації всієї системи
IDOR — це не “баг”. Це багаторівневий провал авторизації.
10. Як виправити IDOR (повноцінна безпека)
10.1. Впровадження перевірки прав доступу (Authorization Check)
Правило №1: сервер завжди має перевіряти, чи належить об’єкт користувачу.
10.2. Використання непрямих ідентифікаторів
- UUID v4
- хешовані ID
- токени доступу
10.3. Повна ізоляція внутрішніх ID
Цифрові ID (auto-increment) не можна використовувати назовні.
10.4. Розмежування доступу (RBAC / ABAC)
Ролі та атрибути мають визначати права доступу.
10.5. Логи + алерти на підозрілу активність
- перебір ID
- доступ до чужих об’єктів
- аномальні запити
10.6. Заголовки авторизації замість ID
Замість:
GET /api/user/55
має бути:
GET /api/user/me
Authorization: Bearer
11. Checklist для виявлення IDOR
- Чи можна змінити ID у URL?
- Чи обмежує застосунок доступ до чужих об’єктів?
- Чи є UUID чи цифрові ID?
- Чи є незалежні внутрішні ідентифікатори?
- Чи повторюється ID у JSON при оновленні профілю?
- Чи дозволяє API переглядати/змінювати чужі записи?
12. Висновок
IDOR — одна з найпростіших, але найсмертоносніших вразливостей.
Вона виникає тоді, коли розробники не впроваджують контроль доступу на рівні об’єктів.
Від масового перебору ID до зламу акаунтів — шлях дуже короткий.
Важливо:
- ніколи не довіряти клієнтським даним
- завжди перевіряти авторизацію на сервері
- не експортувати внутрішні автоінкрементні ID
- використовувати UUID або токени
Якщо правильно побудувати модель доступу — IDOR більше ніколи не виникне у вашій системі.
13. Хочеш наступну статтю на 4000 слів?
Можу зробити:
- Broken Access Control
- Privilege Escalation
- SSRF (розширена версія)
- Business Logic Vulnerabilities
- Authentication Bypass
Просто напиши: ➤ Наступна стаття