Авторка: Катерина Іваненко, Invicti Brand Manager
У сучасному світі з великою кількістю API, однією з найнебезпечніших і найпоширеніших вразливостей є порушена авторизація на рівні об’єктів (Broken Object Level Authorization, BOLA) – яка постійно посідає перші місця в рейтингу OWASP Top 10 щодо безпеки API. Якщо її не виправити, BOLA може дозволити зловмисникам отримувати доступ, змінювати або видаляти конфіденційні дані, що належать іншим користувачам. У цій статті пояснюється, що таке порушена авторизація на рівні об’єктів, як вона працює і, найголовніше, як їй запобігти.
Що таке Broken Object Level Authorization?
BOLA виникає, коли програма не може належним чином перевірити, чи має користувач право доступу до об’єкта, визначеного за допомогою певного ідентифікатора.
Простіше кажучи, це означає, що якщо зловмисник знає або вгадує ідентифікатор об’єкта, яким він не володіє, а система не забезпечує належної перевірки авторизації, таким чином злочинець може отримати доступ до нього або маніпулювати цим об’єктом.
Чому Broken Object Level Authorization така небезпечна?
- Легкість експлуатації: атаки порушеної авторизації на рівні об’єктів вимагають мінімальних навичок – часто це просто зміна ідентифікатора в URL-адресі або запиті до API.
- Витік даних: несанкціонований доступ може розкрити конфіденційну інформацію.
- Втрата репутації: такі інциденти можуть швидко підірвати довіру клієнтів.
- Порушення відповідності: BOLA може призвести до регуляторних штрафів.
Як запобігти вразливості Broken Object Level Authorization
1. Впровадження надійного механізму авторизації, який гарантує, що лише користувачі з відповідними дозволами можуть отримувати доступ або маніпулювати певними ресурсами.
Він має бути:
- На основі ролей або атрибутів: дозволи повинні призначатися на основі ролей користувача (як адміністратор) або атрибутів (наприклад, відділ, регіон).
- Контекстно-залежним: враховує не лише те, хто є користувачем, але й те, до чого він намагається отримати доступ і за яких умов.
- Централізованим: використання централізованої системи контролю доступу для забезпечення узгодженості та простоти аудиту.
- Ієрархічно-залежним: для організацій з багаторівневими структурами.
2. Бекенд повинен перевіряти, чи має користувач право доступу або зміни певного ресурсу щоразу, коли наданий ним ідентифікатор використовується для отримання даних або виконання операції.
Рекомендації:
- Не довіряти вхідним даним клієнта: якщо користувач надсилає дійсний ідентифікатор, не факт, що йому дозволено отримати до нього доступ.
- Завжди перевіряти право власності або доступу. Для кожного API-інтерфейсу, що включає посилання на об’єкти, забезпечити виконання перевірки бекендом. Наприклад, “Чи володіє цей користувач цим об’єктом?” або “Чи має цей користувач дозвіл на читання цього об’єкта?”.
- Не покладатися на фільтри фронтенду: перевірки авторизації повинні відбуватися на сервері, а не на стороні клієнта.
3. Використовувати випадкові ідентифікатори, які важко вгадати, для записів.
4. Проводити регулярне тестування безпеки (наприклад, DAST), яке включає перевірки щодо авторизації на рівні об’єктів.
Наприклад, платформа Invicti, яка об’єднала Netsparker і Acunetix, має додаткові налаштування для автентифікації різними користувачами, що допомагає виявити більше вразливостей BOLA.
Щоб безоплатно протестувати платформу та отримати звіт OWASP Top 10 API Security від Invicti, зв’яжіться з нами зручним для вас способом.
Висновок
Порушена авторизація на рівні об’єктів може становити величезну загрозу навіть для найретельніше розроблених програм. Оскільки API стають складнішими, а дані більш взаємопов’язаними, відсутність надійного контролю доступу на рівні об’єктів може призвести до катастрофічних зламів, від яких важливо захищатися.
