Broken Access Control (OWASP A01:2021): ризик №1 для веб-застосунків

Broken Access Control (порушення контролю доступу) посідає позицію A01:2021 у рейтингу OWASP Top 10 — це ризик номер один для веб-застосунків. У 2017 році він був на п'ятому місці; піднесення пояснюється його поширеністю та високим впливом: OWASP встановив, що 94% протестованих застосунків містили ту чи іншу форму цієї вразливості, і на цю категорію припадає більше входжень Common Weakness Enumeration (CWE), ніж на будь-яку іншу. Контроль доступу починається там, де закінчується автентифікація: автентифікація підтверджує, хто ви; контроль доступу вирішує, що вам дозволено робити. Коли таких рішень немає, вони неповні або перевіряються лише в браузері, зловмисник може прочитати чи змінити дані й функції, які мають бути недоступними.

Що насправді забезпечує контроль доступу

Коректна модель контролю доступу при кожному запиті відповідає на просте питання: чи має право саме цей суб'єкт виконати цю дію над цим конкретним об'єктом? Збої трапляються, коли відповідь припускається, а не перевіряється. Два класичні напрями ескалації — горизонтальна і вертикальна.

• Горизонтальна ескалація — користувач отримує доступ до ресурсів іншого користувача того самого рівня привілеїв. Приклад: користувач A відкриває /api/orders/1043, змінює ID на 1044 і читає замовлення користувача B. Та сама роль, інший власник.
• Вертикальна ескалація — користувач отримує можливості вищого рівня привілеїв. Приклад: звичайний користувач викликає POST /api/admin/users для створення акаунтів або підмінює приховане поле role=admin. Зовсім інша роль.

Найпоширеніші шаблони вразливостей

IDOR / BOLA (Insecure Direct Object Reference / Broken Object Level Authorization). Це флагманська помилка горизонтальної ескалації, а як BOLA вона посідає позицію API1:2023 в OWASP API Security Top 10. Застосунок розкриває пряме посилання на об'єкт — ідентифікатор у базі даних, ім'я файлу, UUID — і довіряє клієнту передавати лише ті посилання, якими він володіє. Оскільки сервер ніколи повторно не перевіряє володіння, підміна ідентифікатора повертає чужі дані. Передбачувані послідовні ідентифікатори (?invoice=8801) роблять перебір тривіальним, але зауважте: заміна їх на UUID — це обфускація, а не контроль. Рішення — перевірка володіння на стороні сервера, а не невгадуваний ідентифікатор.

Відсутність авторизації на рівні функцій. Адміністративні або привілейовані функції захищені лише тим, що посилання не показується в інтерфейсі. Сам endpoint не перевіряє роль. Зловмисник, який знає або вгадав /admin/delete-user — часто легко знаходжуваний у JavaScript-бандлах або через фазинг — викликає його напряму. Це відповідає CWE-285 (Improper Authorization) та CWE-862 (Missing Authorization).

Примусовий перегляд (forced browsing). Зловмисник запитує URL, параметри або HTTP-методи, які ніде не пов'язані посиланнями, але все одно обслуговуються. Прямий запит /reports/2026/q1-confidential.pdf або надсилання PUT/DELETE на endpoint, що захищає лише GET, обходить контроль, який припускав, що користувачі переходитимуть лише за наданими посиланнями. Часті знахідки — endpoint'и метаданих, файли резервних копій і налагоджувальні маршрути.

Інші часті варіанти: неправильна конфігурація CORS, що відкриває API недовіреним джерелам; JWT, чиї твердження (як-от role чи sub) приймаються без перевірки підпису; та mass-assignment, коли тіло запиту задає поля (isAdmin, accountBalance), які клієнт ніколи не має контролювати.

Реальні наслідки

Збої контролю доступу не теоретичні. Вразливість USPS Informed Delivery 2018 року дозволяла будь-якому авторизованому користувачу запитувати дані акаунтів ~60 мільйонів користувачів через неавтентифікований параметр API — хрестоматійний BOLA. Витік First American Financial 2019 року розкрив 885 мільйонів іпотечних записів через послідовні ідентифікатори документів, що не вимагали жодної автентифікації. За CVSS v3.1 такі проблеми часто набирають 8,0+ (High) — наприклад, віддалено експлуатований IDOR, що розкриває конфіденційні дані, набирає CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6,5, наближаючись до 8–9, коли доступні також цілісність або адміністративні функції.

Як це тестувати

• Диференційне тестування двох акаунтів. Створіть двох користувачів (і одного адміністратора). Перехопіть запит від акаунта A, потім відтворіть його з cookie/токеном сесії акаунта B. Якщо B отримує дані A — у вас помилка горизонтального доступу. Інструменти на кшталт Autorize або Auth Analyzer у Burp Suite автоматизують це порівняння.
• Підміна параметрів. Збільшуйте, зменшуйте і фазьте кожен ідентифікатор об'єкта — ID, UUID, імена файлів, номери рахунків — включно з тими, що в тілі JSON та у твердженнях JWT.
• Зондування на рівні функцій. Перелічіть адміністративні та привілейовані endpoint'и з source map JS і брутфорсом каталогів, потім викликайте їх із низькопривілейованою сесією.
• Тестування методів і примусового перегляду. Пробуйте альтернативні HTTP-дієслова і напряму запитуйте непов'язані ресурси. Узгодьте охоплення з тест-кейсами OWASP WSTG-ATHZ (Authorization Testing).

Як це запобігти

• Забороняти за замовчуванням (deny by default). Кожен ресурс приватний, доки правило явно не надасть доступ. Публічні endpoint'и — це виняток, який ви додаєте до білого списку, а не замовчування, яке забуваєте заблокувати.
• Завжди перевіряйте на стороні сервера. Перевірки на стороні клієнта — це UX, а не безпека. Авторитетне рішення має ухвалюватися на сервері, при кожному запиті, для кожного об'єкта.
• Перевіряйте володіння, а не лише роль. Переконайтеся, що автентифікований суб'єкт справді володіє цим записом або має на нього право. Визначайте особу користувача із сесії/токена — ніколи з переданого клієнтом параметра user_id.
• Централізуйте логіку. Спрямовуйте всі рішення через єдиний компонент авторизації або middleware, а не розкидайте розрізнені перевірки if. Це відповідає NIST SP 800-53 AC-3 (Access Enforcement) та принципу найменших привілеїв (AC-6).
• Використовуйте непрямі посилання й обмежуйте частоту. Надавайте перевагу посиланням, відображеним per-сесія, логуйте збої контролю доступу й сповіщайте про повторні відмови, щоб виявити перебір.
• Тестуйте безперервно. Додайте автоматичні тести авторизації до CI, щоб новий endpoint не міг потрапити в продакшн без перевірки володіння.

Контроль доступу — це проєктна робота, а не фільтр, приклеєний наприкінці. Явно моделюйте ролі та володіння об'єктами, забезпечуйте кожне рішення на стороні сервера за принципом deny-by-default і перевіряйте це тестуванням двох акаунтів при кожному релізі. Саме ця дисципліна перетворює ризик №1 з OWASP на незначну подію.