Unrestricted Resource Consumption

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

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

Поширеність

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

Впливи

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

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

Для задоволення запитів API потрібні такі ресурси, як пропускна здатність мережі, ЦП, пам’ять і сховище. Іноді необхідні ресурси надаються постачальниками послуг через інтеграцію API та оплачуються за запит, як-от надсилання електронних листів/SMS/телефонних дзвінків, перевірка біометричних даних тощо.

API вразливий, якщо принаймні один із наведених нижче обмежень відсутній або встановлено неналежним чином (наприклад, занадто низький/високий):

Час очікування виконання
Максимально доступна пам'ять
Максимальна кількість дескрипторів файлів
Максимальна кількість процесів
Максимальний розмір файлу для завантаження
Кількість операцій для виконання в одному запиті клієнта API (наприклад, пакетування GraphQL)
Кількість записів на сторінку для повернення в одному запиті-відповіді
Ліміт витрат сторонніх постачальників послуг

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

Сценарій №1

Соціальна мережа реалізувала механізм «забули пароль» за допомогою SMS-підтвердження, дозволяючи користувачеві отримати одноразовий маркер через SMS, щоб скинути свій пароль.

Коли користувач натискає «забув пароль», виклик API надсилається з браузера користувача до внутрішнього API:

POST /initiate_forgot_password { "step": 1, "user_number": "6501113434" }

Потім API запит надсилається з серверної частини до стороннього API, який піклується про доставку SMS:

POST /sms/send_reset_pass_code Host: willyo.net { "phone_number": "6501113434" }

Сторонній постачальник, Willyo, стягує плату в розмірі 0,05 доларів США за такий тип виклику.

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

Сценарій №2

Кінцева точка GraphQL API дозволяє користувачеві завантажувати зображення профілю.

POST /graphql { "query": "mutation { uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { url } }" }

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

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

Зловмисник може легко обійти ці механізми, використовуючи гнучку природу GraphQL:

POST /graphql [ {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, ... {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, }

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

Сценарій №3

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

Коли один із файлів оновлюється, його розмір збільшується до 18 ГБ. Всі клієнтські служби негайно починають підтягувати нову версію. Оскільки не було сповіщень про вартість споживання та сповіщень на яку максимальну суму вартості коштуватиме для хмарної служби, наступний щомісячний рахунок зростає в середньому з 13 доларів США до 8 тисяч доларів США.

Як запобігти

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