Broken Object Property Level Authorization

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

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

Поширеність

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

Впливи

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

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

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

Кінцева точка API є вразливою, якщо:

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

• Кінцева точка API дозволяє користувачеві змінювати, додавати/видалити значення властивості конфіденційного об’єкта, до якого користувач не повинен мати доступу.

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

Сценарій №1

Додаток для знайомств дозволяє користувачеві повідомляти про неприйнятну поведінку інших користувачів. У рамках цього процесу користувач натискає кнопку «повідомити», і запускається такий виклик API:

POST /graphql { "operationName":"reportUser", "variables":{ "userId": 313, "reason":["offensive behavior"] }, "query":"mutation reportUser($userId: ID!, $reason: String!) { reportUser(userId: $userId, reason: $reason) { status message reportedUser { id fullName recentLocation } } }" }

Кінцева точка API є вразливою, оскільки вона дозволяє автентифікованому користувачеві мати доступ до конфіденційних об’єктів іншого користувача, таких як «fullName» і «recentLocation», до яких інші користувачі не повинні мати доступу.

Сценарій №2

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

Виклик API надсилається хостом POST /api/host/approve_booking із таким пейлойдом:

{ "approved": true, "comment": "Check-in is after 3pm" }

Хост відтворює легітимний запит і додає таке зловмисне навантаження:

{ "approved": true, "comment": "Check-in is after 3pm", "total_stay_price": "$1,000,000" }

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

Сценарій №3

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

PUT /api/video/update_video { "description": "a funny video about cats" }

Розчарований користувач може відтворити законним запитом і додати наступне зловмисне навантаження:

{ "description": "a funny video about cats", "blocked": false }

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

Як запобігти

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

• Уникайте використання загальних методів, таких як to_json() і to_string(). Замість цього виберіть конкретні властивості об’єкта, які ви хочете повернути.

• Якщо можливо, уникайте використання функцій, які автоматично прив’язують вхідні дані клієнта до змінних коду.

• Дозволити змінювати лише ті властивості об’єкта, які клієнт має оновити.

• Запровадити механізм перевірки відповіді на основі схеми як додатковий рівень безпеки.

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