Що таке IDOR і як захистити чужі дані
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: IDOR (Insecure Direct Object Reference) — це вразливість, за якої застосунок дозволяє отримати доступ до чужого ресурсу за його ідентифікатором без належної перевірки прав. Наприклад, користувач змінює номер рахунку в адресі й бачить документ іншого клієнта. Проблема не в самому номері в адресі, а в тому, що сервер не перевіряє, чи має ця людина право доступу до цього рахунку.
Як працює IDOR — простий приклад
Уявіть кабінет клієнта, у якому після входу ви завантажуєте власний рахунок. Браузер надсилає серверу запит до шляху /rakhunky/481, а застосунок повертає документ із номером 481.
Сама по собі така адреса — цілком звичайне рішення. Вразливість виникає тоді, коли зміна шляху на /rakhunky/482 дозволяє завантажити рахунок іншого клієнта, хоча доступу до нього вам не надавали.
Це нагадує гардероб, у якому працівник видає пальто кожному, хто назве номер вішалки, замість того щоб перевірити право його забрати. Номер указує на річ, але не підтверджує права її отримати.
«Об’єкт» у назві IDOR тут означає ресурс застосунку: документ, замовлення, фото, повідомлення або обліковий запис. «Пряме посилання» означає звернення до цього ресурсу за ідентифікатором. Це не обов’язково порядкове число — ідентифікатором може бути назва файлу, адреса електронної пошти або довгий рядок символів.
Чому самого входу в обліковий запис недостатньо
Автентифікація відповідає на запитання: «Хто ви?». Авторизація, тобто перевірка прав, відповідає на інше: «Що вам дозволено робити?». Застосунок може правильно розпізнати користувача, який увійшов у систему, але водночас надавати йому чужі дані.
Захищений сервер має перевірити не лише те, чи існує рахунок, а й те, чи може користувач його переглядати. Право доступу може залежати від того, кому належить документ, від ролі в організації або від того, чи було іншій людині свідомо надано доступ до нього.
IDOR не обмежується переглядом інформації. Відсутність перевірки може також дозволити змінити або видалити чужий ресурс, наприклад адресу доставки в замовленні. Право на перегляд не означає автоматичного права на редагування, тому кожна операція потребує відповідної перевірки.
Якщо застосунок обслуговує багато компаній, важливе й розмежування доступу між організаціями. Адміністратор однієї компанії не повинен отримувати доступ до даних іншої лише тому, що знає ідентифікатор її документа.
Де може міститися ідентифікатор, через який виникає вразливість
Ідентифікатор не обов’язково видно в адресному рядку. Він може міститися в параметрах запиту, у тілі запиту, який надсилає форма, або у виклику API — інтерфейсу для взаємодії між програмами.
Типові операції, що потребують перевірки прав:
- завантаження рахунків, вкладень і експортованих даних;
- перегляд повідомлень, звернень і замовлень;
- оновлення профілю або налаштувань облікового запису;
- видалення файлів та інших ресурсів.
Не кожен випадок доступу після зміни ідентифікатора означає помилку. Публічний допис у блозі має бути доступний усім, а спільний документ — співробітникам із відповідними правами. Ознакою вразливості є порушення встановлених правил доступу, а не сама можливість указати інший об’єкт.
Подібні помилки в API іноді описують як BOLA (Broken Object Level Authorization), тобто неналежну перевірку прав на рівні конкретного об’єкта. Ці назви тісно пов’язані; практичне запитання залишається тим самим: чи перевіряє сервер право користувача на доступ до вказаного ресурсу та виконання відповідної дії?
Що справді захищає від IDOR
Основний захист — перевірка прав на боці сервера під час кожного звернення до ресурсу. Приховати кнопку в інтерфейсі недостатньо, адже запит можна надіслати й без неї.
У прикладі з рахунками застосунок має шукати документ серед тих, що доступні цьому користувачеві, або перевіряти права, перш ніж повернути документ. Він не повинен вважати передане браузером поле «власник» доказом того, кому належить документ.
Випадкові ідентифікатори, як-от UUID, ускладнюють вгадування адрес, але не замінюють авторизацію. Якщо ідентифікатор стане відомим стороннім, наприклад через поширене посилання, сервер усе одно має відмовити в доступі людині без відповідних прав.
Корисний принцип — відмова за замовчуванням: якщо застосунок не може підтвердити право на операцію, він її не виконує. Перевірка має охоплювати також завантаження файлів і експорт даних, а не лише головний екран документа.
Як безпечно перевірити власний застосунок
Виконуйте такий тест лише в системі, яка належить вам або на тестування якої ви маєте дозвіл. Найкраще використовувати тестове середовище й вигадані дані, особливо для операцій зміни та видалення.
- Створіть два тестові облікові записи: A і B, без ресурсів, до яких вони надали один одному доступ.
- В обліковому записі A створіть документ і запишіть його ідентифікатор.
- Увійдіть як B і спробуйте переглянути цей документ через передбачений інтерфейс або API.
- Окремо перевірте можливість редагування, завантаження та видалення, якщо такі дії передбачено.
- Перевірте не лише наявність повідомлення про відмову, а й те, чи жодні дані не були розкриті або змінені.
Сервер має відмовити у виконанні недозволеної операції; він також може навмисно не повідомляти, чи існує документ. Такий сценарій варто додати до автоматизованих тестів, щоб зміни в коді не призвели до повторної появи вразливості.
Дивіться також: Що таке 2FA?
Читайте також
