Блог з безпеки

OWASP Top 10 з безпеки API: Необмежене споживання ресурсів

ResilientX

Вступ до необмеженого споживання ресурсів

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

Агенти загроз та вектори атак

Агенти загроз

Агенти загроз, пов’язані з необмеженим споживанням ресурсів (API4:2023), можуть бути різними, але зазвичай це зловмисники або автоматизовані інструменти, створені для експлуатації вразливостей в API. Цих агентів загроз можна поділити на такі категорії:

  1. Зовнішні зловмисники: це окремі особи або групи, які намагаються експлуатувати вразливості в API задля власної вигоди або щоб спричинити збої.
  2. Зловмисні інсайдери: користувачі з авторизованим доступом, які зловживають своїми привілеями, щоб експлуатувати API зі зловмисною метою.
  3. Автоматизовані боти: програми або скрипти, створені для автоматичного надсилання великої кількості запитів до API з метою вичерпання системних ресурсів.

Вектори атак

Вектори атак для необмеженого споживання ресурсів (API4:2023) зазвичай спрямовані на перевантаження цільового API надмірною кількістю запитів або на надмірне споживання ресурсів. Серед найпоширеніших векторів атак:

  1. Запити великого обсягу: зловмисники можуть надсилати велику кількість запитів до API з одного локального комп’ютера або з використанням хмарних обчислювальних ресурсів. Це може швидко перевантажити пропускну здатність цільового API та вичерпати його ресурси.
  2. Маніпуляція параметрами: зловмисники можуть формувати запити до API з параметрами, що визначають кількість ресурсів, які повертаються. Маніпулюючи цими параметрами, вони можуть змусити API споживати надмірну кількість ресурсів.
  3. Аналіз відповідей: зловмисники можуть аналізувати статус, час або довжину відповідей на запити до API, щоб виявити потенційні слабкі місця. Експлуатуючи ці слабкі місця, вони можуть спричинити вичерпання ресурсів.
  4. Пакетні операції: API, що підтримують пакетні операції, особливо вразливі. Зловмисники можуть використовувати пакетні операції для виконання великої кількості ресурсомістких завдань у межах одного запиту до API.

Слабкі місця безпеки

Необмежене споживання ресурсів (API4:2023) корениться у слабких місцях безпеки, що існують в API. До таких слабких місць належать:

  1. Відсутність обмежень на ресурси: багато API не впроваджують належних обмежень на взаємодію з клієнтами чи споживання ресурсів. Це дає зловмисникам змогу експлуатувати API, перевантажуючи його надмірною кількістю запитів або споживаючи надмірну кількість ресурсів.
  2. Недостатня валідація вхідних даних: в API можуть бути відсутні належні механізми валідації вхідних параметрів і корисного навантаження. Без належної валідації зловмисники можуть маніпулювати вхідними даними, щоб спричинити споживання ресурсів понад допустимі межі.
  3. Неналежне обмеження частоти запитів: в API часто бракує ефективних механізмів обмеження частоти запитів для контролю частоти взаємодії з клієнтами. Без таких обмежень зловмисники можуть засипати API великою кількістю запитів, що призводить до вичерпання ресурсів.
  4. Слабка валідація рядка запиту та тіла запиту: API можуть не виконувати ретельної валідації параметрів рядка запиту та тіла запиту. Зловмисники можуть маніпулювати цими параметрами, щоб контролювати кількість записів, які повертаються у відповіді API, що призводить до надмірного споживання ресурсів.

Наслідки

Необмежене споживання ресурсів (API4:2023) може мати серйозні наслідки як для технічних, так і для бізнесових аспектів організації. До цих наслідків належать:

  1. Відмова в обслуговуванні (DoS): перевантажуючи API надмірною кількістю запитів, зловмисники можуть спричинити стан DoS, роблячи API недоступним для легітимних користувачів і порушуючи роботу бізнесу.
  2. Збільшення операційних витрат: необмежене споживання ресурсів може призвести до зростання операційних витрат організації. Це охоплює витрати на інфраструктуру, як-от зросле навантаження на CPU та потреби у хмарному сховищі, що виникають унаслідок надмірного споживання ресурсів.
  3. Погіршення якості обслуговування: коли ресурси API вичерпані, якість обслуговування, яке надає API, може погіршуватися, що призводить до повільнішого часу відповіді та зниження функціональності.
  4. Репутаційні збитки: успішна атака на API може суттєво зашкодити репутації організації, що призводить до втрати довіри клієнтів і потенційних фінансових втрат.

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

Щоб проілюструвати вплив необмеженого споживання ресурсів (API4:2023), розгляньмо три сценарії атак.

Сценарій №1: SMS-флуд-атака

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

Зловмисник пише скрипт, який надсилає велику кількість запитів на відновлення пароля до API соціальної мережі. Кожен виклик API запускає запит на надсилання SMS до стороннього API, що стягує $0.05 за кожен запит. Засипавши API соціальної мережі десятками тисяч запитів, зловмисник змушує компанію втратити тисячі доларів за короткий проміжок часу.

Сценарій №2: вичерпання пам’яті через GraphQL

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

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

Сценарій №3: неконтрольоване завантаження файлів

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

Коли файл оновлюється і його розмір зростає до 18GB, усі клієнти одразу починають завантажувати нову версію. Через відсутність сповіщень про вартість споживання чи ліміту максимальних витрат постачальник послуг стикається зі значним зростанням щомісячних рахунків — у середньому з $13 до $8,000.

Як запобігти необмеженому споживанню ресурсів (API4:2023)

Щоб зменшити ризики, пов’язані з необмеженим споживанням ресурсів (API4:2023), організації можуть впровадити такі запобіжні заходи:

  1. Використовуйте рішення для обмеження ресурсів: застосовуйте контейнеризацію або безсерверні фреймворки коду (наприклад, Lambdas), які дають змогу легко обмежувати такі ресурси, як пам’ять, CPU, кількість перезапусків, файлові дескриптори та процеси. Такі рішення забезпечують кращий контроль над споживанням ресурсів.
  2. Впроваджуйте валідацію вхідних даних: визначте та застосовуйте максимальні обмеження розміру для всіх вхідних параметрів і корисного навантаження. Це охоплює встановлення максимальної довжини рядків, максимальної кількості елементів у масивах і максимального розміру файлу для завантаження. Належна валідація вхідних даних допомагає запобігти вичерпанню ресурсів, спричиненому зловмисними маніпуляціями.
  3. Застосовуйте обмеження частоти запитів: впровадьте механізми обмеження частоти запитів, щоб контролювати, як часто клієнти можуть взаємодіяти з API у визначений проміжок часу. Тонко налаштовуйте обмеження частоти запитів відповідно до потреб бізнесу, забезпечуючи, щоб різні кінцеві точки API мали належні політики обмеження частоти запитів.
  4. Обмежуйте виконання окремих операцій: обмежуйте кількість разів або частоту, з якою окремий клієнт/користувач API може виконувати певну операцію. Наприклад, обмежте перевірку одноразового пароля або запитів на відновлення пароля без необхідності переходу за одноразовим URL.
  5. Виконуйте валідацію на боці сервера: впровадьте комплексну валідацію на боці сервера для параметрів рядка запиту та тіла запиту. Зокрема, перевіряйте параметри, що визначають кількість записів, які повертаються у відповіді API, запобігаючи надмірному споживанню ресурсів.
  6. Налаштуйте ліміти витрат і сповіщення: встановіть ліміти витрат для всіх постачальників послуг / інтеграцій API. Якщо встановити ліміти витрат неможливо, налаштуйте сповіщення про виставлення рахунків, щоб відстежувати й контролювати витрати, пов’язані зі споживанням ресурсів.

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

Висновок

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

Пов’язані ресурси

ПоділитисяLinkedInX
Пов’язані статті блогу
Пов’язані статті блогу
Нічого не знайдено.

Готові зменшити свою кіберекспозицію?

Дізнайтеся, як ResilientX забезпечує безперервну видимість вашої поверхні атаки, ризиків третіх сторін і стану відповідності — в одній платформі.

Забронюйте демо