Broken Object Level Authorization

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

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

Поширеність

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

Впливи

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

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

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

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

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

Порівняння ідентифікатора користувача поточного сеансу (наприклад, вилучення його з маркера JWT) із параметром вразливого ідентифікатора не є достатнім рішенням для вирішення проблеми авторизації на рівні зламаного об’єкта (IDOR). Цей підхід може стосуватися лише невеликої кількості випадків.

У випадку IDOR користувач має доступ до вразливої кінцевої точки/функції API. Порушення відбувається на рівні об’єкта шляхом маніпулювання ідентифікатором. Якщо зловмиснику вдається отримати доступ до кінцевої точки/функції API, до якої він не повинен мати доступу - це випадок авторизації рівня порушеної функції (BFLA), а не IDOR.

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

Сценарій №1

Платформа електронної комерції для онлайн-магазинів надає сторінку списку з діаграмами доходів. Перевіряючи запити браузера, зловмисник може ідентифікувати кінцеві точки API, які використовуються як джерело даних для цих діаграм, і їх шаблон: /shops/{shopName}/revenue_data.json. Використовуючи іншу кінцеву точку API, зловмисник може отримати список усіх назв розміщених магазинів. За допомогою простого сценарію для маніпулювання іменами в списку, замінюючи {shopName} URL, зловмисник отримує доступ до даних про продажі тисяч магазинів електронної комерції.

Сценарій №2

Виробник автомобілів увімкнув дистанційне керування своїми автомобілями через мобільний API для зв’язку з мобільного телефона водія. API дозволяє водієві дистанційно запускати й зупиняти двигун, а також замикати й відмикати двері. У рамках цього потоку користувач надсилає ідентифікаційний номер автомобіля (VIN) до API. API не в змозі перевірити, що VIN представляє транспортний засіб, який належить користувачу, який увійшов у систему, що призводить до вразливості IDOR. Зловмисник може отримати доступ до транспортних засобів, які йому не належать.

Сценарій №3

Онлайн-служба зберігання документів дозволяє користувачам переглядати, редагувати, зберігати та видаляти свої документи. Коли документ користувача видаляється, мутація GraphQL з ідентифікатором документа надсилається в API.

POST /graphql { "operationName":"deleteReports", "variables":{ "reportKeys":["<DOCUMENT_ID>"] }, "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { { deleteReports(reportKeys: $reportKeys) } }" }

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

Як запобігти

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