Broken Function Level Authorization

Особливості цієї вразливості

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

Поширеність

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

Впливи

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

Як зрозуміти що API вразлива?

Найкращий спосіб виявити порушення авторизації на рівні функцій – це виконати глибокий аналіз механізму авторизації, пам’ятаючи про ієрархію користувачів, різні ролі чи групи в програмі та поставивши такі запитання:

• Чи може звичайний користувач отримати доступ до адміністративних кінцевих точок?

• Чи може користувач виконувати конфіденційні дії (наприклад, створення, зміна чи видалення), до яких він не повинен мати доступу, просто змінивши метод HTTP (наприклад, з на GET) DELETE?

• Чи може користувач із групи X отримати доступ до функції, яка має бути доступна лише користувачам із групи Y, просто вгадавши URL-адресу кінцевої точки та параметри (наприклад, /api/v1/users/export_all)?

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

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

Сценарій №1

Під час процесу реєстрації в програмі, яка дозволяє приєднатися лише запрошеним користувачам, мобільна програма ініціює виклик API до GET /api/invites/{invite_guid}. Відповідь містить файл JSON із деталями про запрошення, зокрема роль користувача та електронну адресу користувача.

Зловмисник дублює запит і маніпулює методом і кінцевою точкою HTTP до POST /api/invites/new. Доступ до цієї кінцевої точки мають мати лише адміністратори за допомогою консолі адміністратора. Кінцева точка не реалізує перевірки авторизації на функціональному рівні.

Зловмисник використовує проблему та надсилає нове запрошення з правами адміністратора:

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

Пізніше зловмисник використовує зловмисно створене запрошення, щоб створити собі обліковий запис адміністратора та отримати повний доступ до системи.

Сценарій №2

API містить кінцеву точку, яка має бути доступна лише адміністраторам – GET /api/admin/v1/users/all. Ця кінцева точка повертає відомості про всіх користувачів програми та не реалізує перевірки авторизації на рівні функції. Зловмисник, який дізнався про структуру API, обґрунтовано припускає та отримує доступ до цієї кінцевої точки, яка розкриває конфіденційні дані користувачів програми.

Як запобігти

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

• Механізм(и) примусового виконання має забороняти будь-який доступ за замовчуванням, вимагаючи явного надання певним ролям доступу до кожної функції.

• Перевірте свої кінцеві точки API на наявність недоліків авторизації на функціональному рівні, пам’ятаючи про бізнес-логіку програми та ієрархію груп.

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

• Переконайтеся, що адміністративні функції всередині звичайного контролера здійснюють перевірки авторизації на основі групи та ролі користувача.