Блог з безпеки

OWASP Top 10 для безпеки API: порушена авторизація на рівні функцій

5 хв читання

ResilientX

Вступ

API (програмні інтерфейси застосунків) відіграють вирішальну роль у сучасній розробці застосунків, даючи різним програмним системам змогу обмінюватися даними. Однак API можуть створювати вразливості безпеки, якщо їх реалізовано та захищено неналежно. Одна з таких вразливостей — порушена авторизація на рівні функцій (Broken Function Level Authorization), яка може призвести до несанкціонованого доступу до конфіденційної функціональності та даних усередині застосунку. У цій статті ми розглянемо джерела загроз, вектори атак, слабке місце безпеки та наслідки, пов’язані з порушеною авторизацією на рівні функцій. Ми також наведемо три приклади з кодом, щоб продемонструвати, як можна експлуатувати цю вразливість, і обговоримо запобіжні заходи.

Розуміння порушеної авторизації на рівні функцій

Джерела загроз і вектори атак

Джерелами загроз в атаках з порушеною авторизацією на рівні функцій зазвичай є зловмисники, які прагнуть отримати несанкціонований доступ до привілейованої функціональності чи конфіденційних даних усередині застосунку. Вектори атак передбачають експлуатацію відсутності належних перевірок авторизації для ендпоінтів API. Зловмисники можуть надсилати легітимні виклики API до ендпоінтів, доступу до яких вони не повинні мати, — як анонімні користувачі або звичайні непривілейовані користувачі.

Слабке місце безпеки

Слабке місце безпеки в порушеній авторизації на рівні функцій полягає в неправильній реалізації перевірок авторизації для функцій чи ресурсів. Перевірки авторизації зазвичай керуються на рівні конфігурації або коду, де права доступу надаються на основі ролей, груп чи ієрархій користувачів. Однак реалізація належних перевірок може бути складним завданням, особливо в сучасних застосунках із численними ролями, групами та заплутаними ієрархіями користувачів. Через цю складність зловмисникам легше виявляти вади в API, адже API більш структуровані, а доступ до різних функцій часто передбачуваніший.

Наслідки

Експлуатація вразливостей порушеної авторизації на рівні функцій може мати серйозні технічні та специфічні для бізнесу наслідки. Отримання зловмисниками несанкціонованого доступу до конфіденційної функціональності може призвести до різних наслідків, як-от:

Розкриття даних: зловмисники можуть отримати доступ до конфіденційної інформації чи чутливих даних, які мають бути доступні лише авторизованим користувачам. Це може призвести до розкриття персональних даних, комерційних таємниць чи іншої критично важливої інформації.
Втрата даних: несанкціонований доступ до адміністративних функцій потенційно може призвести до втрати чи пошкодження даних. Зловмисники можуть маніпулювати даними або видаляти їх, завдаючи значної шкоди застосунку та його користувачам.
Порушення роботи сервісу: експлуатуючи адміністративні функції, зловмисники можуть порушити нормальну роботу застосунку. Це може призвести до простою сервісу, втрати доступності та потенційних фінансових втрат для бізнесу.

З огляду на серйозність цих наслідків, критично важливо виявляти та усувати вразливості порушеної авторизації на рівні функцій в API.

Чи вразливий API?

Щоб визначити, чи вразливий API до порушеної авторизації на рівні функцій, потрібен комплексний аналіз механізму авторизації. Важливо враховувати ієрархію користувачів, різні ролі чи групи в застосунку та ставити відповідні запитання. Ось кілька ключових запитань, які варто розглянути:

Чи може звичайний користувач отримати доступ до адміністративних ендпоінтів?
Чи може користувач виконувати конфіденційні дії, до яких не повинен мати доступу, просто змінивши HTTP-метод?
Чи може користувач з однієї групи отримати доступ до функції, яка має бути доступна лише користувачам з іншої групи, вгадавши URL-адресу ендпоінта та параметри?

Важливо не припускати, що ендпоінт API є звичайним чи адміністративним, лише на основі шляху URL. Хоча розробники можуть розміщувати більшість адміністративних ендпоінтів під певним відносним шляхом, як-от /api/admins, часто трапляється, що адміністративні ендпоінти змішані зі звичайними під іншими відносними шляхами, як-от /api/users.

Ретельний аналіз механізмів авторизації API та ці запитання допомагають виявити потенційні вразливості.

Приклади сценаріїв атак

Розгляньмо три сценарії атак, які демонструють, як можна експлуатувати вразливості порушеної авторизації на рівні функцій.

Сценарій №1: несанкціоновані права адміністратора

Під час реєстрації в застосунку, який дозволяє приєднуватися лише запрошеним користувачам, мобільний застосунок ініціює виклик API, щоб

отримати деталі запрошення:

GET /api/invites/{invite_guid}

Відповідь містить JSON із деталями про запрошення, зокрема роль та електронну адресу користувача. Зловмисник дублює запит, маніпулює HTTP-методом та ендпоінтом і надсилає шкідливий запит, щоб створити нове запрошення з правами адміністратора:

POST /api/invites/new { "email": "attacker@somehost.com", "role":"admin" }

Оскільки ендпоінт, відповідальний за створення запрошень, не реалізує належних перевірок авторизації, зловмисник успішно створює обліковий запис адміністратора й отримує повний доступ до системи.

Сценарій №2: несанкціонований доступ до даних користувачів

API містить ендпоінт, який має бути доступний лише адміністраторам:

GET /api/admin/v1/users/all

Цей ендпоінт повертає деталі всіх користувачів застосунку. Однак він не реалізує належних перевірок авторизації на рівні функцій. Зловмисник, обізнаний зі структурою API, робить обґрунтоване припущення й отримує доступ до цього ендпоінта, розкриваючи конфіденційні дані користувачів.

Сценарій №3: вгадування URL-адрес ендпоінтів

У цьому сценарії API має різні ендпоінти для експорту даних користувачів залежно від груп користувачів. Зловмисник намагається отримати доступ до ендпоінта, який має бути доступний лише користувачам з групи Y, але помилково вгадує URL-адресу та параметри:

/api/v1/users/export_all

Експлуатуючи цю ваду в авторизації на рівні функцій, зловмисник отримує несанкціонований доступ до функції експорту, призначеної для користувачів з групи Y.

Ці сценарії ілюструють реальні ризики, пов’язані з вразливостями порушеної авторизації на рівні функцій, і підкреслюють важливість реалізації належних перевірок авторизації.

Як запобігти порушеній авторизації на рівні функцій

Запобігання порушеній авторизації на рівні функцій потребує реалізації надійних механізмів авторизації та проведення ретельних оцінок безпеки. Ось кілька запобіжних заходів:

Узгоджений модуль авторизації: ваш застосунок повинен мати узгоджений і простий для аналізу модуль авторизації, який викликається з усіх бізнес-функцій. Цей модуль має забезпечувати належний контроль доступу, за замовчуванням відмовляючи в будь-якому доступі та вимагаючи явних дозволів для конкретних ролей на доступ до кожної функції.
Перегляд ендпоінтів API: регулярно переглядайте свої ендпоінти API на предмет потенційних вад авторизації на рівні функцій. Враховуйте бізнес-логіку застосунку та ієрархію груп користувачів. Переконайтеся, що конфіденційні функції чи адміністративні контролери реалізують належні перевірки авторизації на основі групи та ролі користувача.
Адміністративний абстрактний контролер: реалізуйте адміністративний абстрактний контролер, який обробляє перевірки авторизації для всіх адміністративних функцій. Усі адміністративні контролери мають успадковуватися від цього абстрактного контролера, щоб забезпечити узгоджену та належну авторизацію на всіх адміністративних ендпоінтах.

Дотримуючись цих запобіжних заходів, ви можете суттєво знизити ризик вразливостей порушеної авторизації на рівні функцій у ваших API.

Висновок

Порушена авторизація на рівні функцій в API може призвести до несанкціонованого доступу до привілейованої функціональності та конфіденційних даних, що потенційно спричиняє серйозні наслідки для бізнесу та користувачів. Розуміння джерел загроз, векторів атак, слабких місць безпеки та наслідків, пов’язаних із цією вразливістю, критично важливе для створення безпечних API. Аналізуючи механізми авторизації, ставлячи відповідні запитання та впроваджуючи запобіжні заходи, розробники можуть зменшити ризики та забезпечити належну безпеку своїх API. Пам’ятайте: захист ваших API — це безперервний процес, і регулярні оцінки безпеки необхідні, щоб залишатися захищеними від загроз, що еволюціонують.