OWASP Top 10 API Security: порушення авторизації на рівні властивостей об’єкта
Вступ
API необхідні для забезпечення комунікації та обміну даними між різними системами. Однак безпека API критично важлива для запобігання несанкціонованому доступу та витокам даних. Одна з вразливостей, що становить значний ризик, — це порушення авторизації на рівні властивостей об’єкта. У цій статті ми розглянемо агентів загроз, вектори атак, слабкості безпеки, наслідки та запобіжні заходи, пов’язані з API3:2023 Broken Object Property Level Authorization.
Агенти загроз і вектори атак
Агентами загроз у цьому контексті зазвичай є користувачі або зловмисники, що взаємодіють із кінцевими точками API. Вектори атак передбачають маніпулювання запитами до API, щоб отримати несанкціонований доступ до чутливих властивостей об’єкта або змінити їхні значення. Різні протоколи можуть вимагати специфічних технік, як-от створення запитів чи використання автоматизованих інструментів, для виявлення властивостей об’єкта та маніпулювання ними.
Слабкість безпеки
Слабкість безпеки полягає в неналежній перевірці доступу користувача до конкретних властивостей об’єкта через кінцеві точки API. API можуть розкривати чутливі властивості об’єкта, які не мають бути доступними користувачам, або дозволяти їм змінювати властивості, до яких у них не повинно бути доступу. Аналіз відповідей API та техніки фазингу можуть виявити чутливу інформацію та приховані властивості. Відсутність належної перевірки може призвести до несанкціонованого доступу, розкриття даних, втрати даних, пошкодження даних, підвищення привілеїв або захоплення облікового запису.
Наслідки
Несанкціонований доступ до приватних або чутливих властивостей об’єкта може призвести до розкриття даних, репутаційних збитків і втрати довіри. Несанкціоновані зміни критичних властивостей можуть спричинити втрату або пошкодження даних. Може відбутися підвищення привілеїв, що надасть зловмисникам вищий рівень доступу та контролю. Часткове чи повне захоплення облікового запису також може становити значні ризики для постраждалих користувачів.
Приклади сценаріїв атак
Сценарій №1: фінансовий застосунок
Кінцева точка API у фінансовому застосунку дає користувачам змогу отримувати баланс свого рахунку. Однак ця кінцева точка не перевіряє авторизацію користувача на доступ до балансів інших користувачів. Розгляньте такий виклик API:
GET /api/account/balance?userId=123456
Зловмисник може використати цю вразливість, змінивши параметр userId, щоб отримати доступ до балансу іншого користувача:
GET /api/account/balance?userId=987654
Щоб цьому запобігти, API має перевіряти, що користувач, який робить запит, має необхідні привілеї для доступу до вказаного балансу рахунку.
Сценарій №2: сайт електронної комерції
Сайт електронної комерції надає кінцеву точку API для оновлення адреси доставки користувача. Однак ця кінцева точка дозволяє користувачам оновлювати адресу будь-якого іншого користувача без належної авторизації. Розгляньте такий виклик API:
PUT /api/user/address
Content-Type: application/json
{
"userId": "123456",
"address": "123 Main St"
}
Зловмисник може використати цю вразливість, змінивши параметр userId, щоб оновити чужу адресу:
PUT /api/user/address
Content-Type: application/json
{
"userId": "987654",
"address": "456 Elm St"
}
Щоб цьому запобігти, API має перевіряти, що користувач, який робить запит, має дозвіл на оновлення адреси вказаного користувача.
Сценарій №3: платформа соціальних мереж
Платформа соціальних мереж дає користувачам змогу залишати коментарі в профілях інших користувачів. Однак кінцева точка API не забезпечує належної авторизації, дозволяючи будь-якому користувачеві залишати коментарі від імені іншого користувача. Розгляньте такий виклик API:
POST /api/profiles/123456/comments
Content-Type: application/json
{
"text": "Great profile!"
}
Зловмисник може використати цю вразливість, змінивши кінцеву точку, щоб залишити коментар у профілі іншого користувача:
POST /api/profiles/987654/comments
Content-Type: application/json
{
"text": "Hacked profile!"
}
Щоб цьому запобігти, API має перевіряти, що користувач, який робить запит, має право залишати коментарі в профілі вказаного користувача.
Впроваджуючи належні перевірки авторизації та валідуючи доступ користувача до конкретних ресурсів, ці вразливості можна усунути, забезпечивши цілісність і безпеку системи.
Запобіжні заходи
Щоб знизити ризики, пов’язані з порушенням авторизації на рівні властивостей об’єкта, впровадьте такі запобіжні заходи:
1. Перевіряйте доступ
Переконайтеся, що користувачі мають відповідний доступ до властивостей об’єкта, розкритих через кінцеві точки API. Розкривайте лише ті властивості, до яких користувачі мають отримувати доступ відповідно до своїх привілеїв.
2. Вибіркове повернення даних
Обирайте конкретні властивості для повернення замість того, щоб розкривати всі властивості об’єкта. Уникайте загальних методів, які можуть ненавмисно розкрити чутливі дані.
3. Уникайте масового присвоєння
Уникайте автоматичного зв’язування вхідних даних клієнта зі змінними коду, внутрішніми об’єктами чи властивостями об’єкта. Дозволяйте змінювати лише ті властивості, які має оновлювати клієнт, і перевіряйте зміни відповідно до правил авторизації.
4. Перевірка відповідей на основі схеми
Впровадьте механізм перевірки відповідей на основі схеми, щоб забезпечити відповідність даних, які повертають методи API, очікуваним. Визначте та застосовуйте структури даних для забезпечення узгодженості й безпеки.
5. Мінімальне розкриття даних
Тримайте структури даних, що повертаються, у мінімальному обсязі, необхідному для бізнес- чи функціональних вимог кінцевої точки. Уникайте розкриття зайвої інформації, що може становити ризики для безпеки.
Висновок
API3:2023 Broken Object Property Level Authorization — це значна вразливість, що може призвести до несанкціонованого доступу, витоків даних та інших згубних наслідків. Розуміючи агентів загроз, вектори атак, слабкості безпеки та потенційні наслідки, організації можуть вживати проактивних заходів для запобігання цим ризикам і їх зниження. Впроваджуючи належну перевірку доступу, вибіркове повернення даних, уникаючи масового присвоєння, застосовуючи перевірку відповідей на основі схеми та мінімізуючи розкриття даних, розробники API можуть забезпечити безпеку й цілісність своїх систем, захищаючи дані користувачів і зберігаючи їхню довіру.
