Безпека API: вичерпний гайд

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

З чого складається безпека API?

На відміну від графічного інтерфейсу, API призначені для автоматизованого обміну даними із зовнішніми системами та між внутрішніми компонентами застосунку. Три основні сфери їх безпеки є вирішальними:

• Виявлення API: визначивши свої внутрішні та зовнішні API, організації можуть створити повнішу картину своєї поверхні атаки. Популярні методи виявлення API включають кроулінг для пошуку файлів специфікацій і API-інтерфейсів, інтеграцію з інструментами керування API та моніторинг трафіку API.
• Тестування безпеки API: після виявлення, їх можна перевірити на вразливості вручну або за допомогою автоматизованого сканування. Хоча ручне тестування API раніше було стандартом, величезна кількість API-інтерфейсів і параметрів сприяли тому, що просунуті інструменти для динамічного тестування безпеки додатків (DAST) тепер широко застосовуються для автоматизації більшої частини перевірок.
• Захист API: більшість компаній використовують шлюз API для маршрутизації їх трафіку через єдину систему з численними заходами безпеки. Це може включати балансування навантаження, обмеження швидкості та брандмауер для вебдодатків (WAF), що забезпечує фільтрацію трафіку API у режимі реального часу.

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

Чому безпека API важлива?

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

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

Існує принаймні п’ять причин, чому безпека API є значущою для організацій:

• Захист конфіденційних даних: API часто надають і обробляють персональну, фінансову та бізнес-інформацію, тому кібератаки на них можуть спричинити витік даних.
• Безпека поверхні атаки додатків: без належного захисту, API-інтерфейси можуть стати точками входу для злочинців.
• Зниження вірогідності просунутих та інтенсивних атак: оскільки API розроблені для автоматизованого доступу, вони часто стають цілями зловмисників. Суворі заходи безпеки API можуть запобігти або зменшити вплив цих руйнівних атак.
• Відповідність нормативним стандартам: вони вимагають високий рівень безпеки всіх систем, пов’язаних з конфіденційними даними, в тому числі API.
• Підтримка безперервності бізнесу: залежно від архітектури програми, API можуть безпосередньо підтримувати або виконувати критичні бізнес-операції в кількох системах.

В чому різниця між безпекою API та безпекою додатків?

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

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

Безпека різних типів API

Більшість організацій, як правило, використовують один із кількох поширених типів API: REST, SOAP або GraphQL. Хоча заходи безпеки на рівні мережі більше залежать від архітектури додатка, ніж від типу API, безпека різних видів прикладних програмних інтерфейсів на рівні застосунку має свої нюанси.

REST API

REST є найпопулярнішим типом API, який використовується в понад 85% організацій, які мають прикладні програмні інтерфейси. REST (REpresentational State Transfer) – це не суворий протокол або формат, а стиль архітектури. У випадку з ним, HTTP-методи використовуються як типи операцій, і JSON є найпоширенішим форматом даних.

Оскільки кожна операція потребує власного API-інтерфейсу та URL, REST API значно розширюють поверхню атаки. Особливо враховуючи, що запити REST можуть бути дуже передбачуваними. Коли публікується нова специфікація API, стара та нова версії зазвичай тимчасово співіснують. Забуті API, які залишаються у продакшні на невизначений час, є поширеним вектором атаки. Іноді потрібно лише змінити URL з v2 на v1, щоб отримати доступ до менш безпечної версії.

SOAP API

SOAP (Simple Object Access Protocol) це більш давній і менш поширений формат веб API. Він використовується і сьогодні, наприклад, у бізнес-додатках. На відміну від вільного стилю REST, запити SOAP API на основі XML мають суворо відповідати конкретній схемі, що робить їх менш зручними для простих операцій, в тому числі для частих змін під час швидкої розробки.

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

GraphQL API

GraphQL – це не стільки формат API, скільки спеціалізована мова запитів і управління даними для доступу до API баз даних. Попри те, що це відносно новачок у порівнянні з REST і SOAP, він швидко набирає популярність. Його використовують до 30% розробників API.

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

Основні типи вразливостей API

• Вразливості в API: інтерфейс повинен пропускати лише валідні та авторизовані запити. Якщо злочинцям вдається скомпрометувати засоби захисту API, то вони можуть обійти або зламати авторизацію, отримати доступ до API та зробити зловмисні запити. Поширені вразливості прикладних програмних інтерфейсів включають слабкі або незахищені ключі API, несправну автентифікацію, проблему з застосуванням HTTPS для всього трафіку API та неправильне обмеження швидкості, що підвищує ризик DDoS-атак (розподілена відмова в обслуговуванні).

• Вразливості пов’язаних додатків: після обходу або подолання засобів захисту на рівні API зловмисники можуть намагатися експлуатувати вразливості додатків за допомогою викликів API, включаючи поширені атаки ін’єкцій, як-от SQL-ін’єкція, ін’єкція команд і міжсайтовий скриптинг (XSS). У контексті API, вразливість SSRF (server-side request forgery, підробка запитів на стороні сервера). може бути особливо небезпечною, надаючи доступ до внутрішніх систем.

Ризики безпеки OWASP Top 10 для API

Проєкт OWASP підтримує декілька переліків вразливостей, пов’язаних із безпекою вебдодатків, один із них присвячений API. Нижче наведено актуальний список з 2023 року, який можна використовувати як допоміжний ресурс для впровадження заходів безпеки.

• API1:2023 Порушена авторизація на рівні об’єктів
• API2:2023 Порушена автентифікація
• API3:2023 Порушення авторизації на рівні властивостей об’єктів
• API4:2023 Необмежене споживання ресурсів
• API5:2023 Порушена авторизація на рівні функцій
• API6:2023 Необмежений доступ до чутливих бізнес-потоків
• API7:2023 Підробка запиту на стороні сервера
• API8:2023 Неправильна конфігурація безпеки
• API9:2023 Неправильне управління інвентарем
• API10:2023 Небезпечне використання API

Ці ризики безпеки API можна згрупувати в п’ять широких категорій:

1. Авторизація доступу та автентифікація користувачів
2. Контроль і обмеження доступу
3. Управління інвентаризацією API
4. Неправильні налаштування безпеки
5. Невиправлені вразливості вебдодатків

Тестування безпеки API за допомогою DAST

Інструменти автоматизованого динамічного тестування безпеки додатків є хорошим вибором для перевірки поверхні атаки як API, так і графічного інтерфейсу. Але дуже небагато сканерів вебвразливостей достатньо просунуті та точні, щоб безпечно виконувати численні перевірки та надавати надійні результати.

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

• Підтримка дефініцій REST, SOAP, GraphQL і gRPC
• Виявлення API: як задокументованих, так і невідомих
• Повністю автоматизоване автентифіковане сканування
• Централізована видимість API-інтерфейсів і вразливостей
• Автоматичне переписування URL-адрес для покращення тестування безпеки
• Сотні перевірок для безпечного й точного виявлення вразливостей

Найкращі практики для безпеки API

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

• Визначення стратегії безпеки API. Це повинно включати політики та засоби для виявлення API, тестування безпеки, інвентаризації, керування та захисту.
• Для великих API в продакшні варто використовувати перевірені рішення безпеки для захисту під час виконання. Це має охоплювати контроль доступу, а також автоматизовану фільтрацію та обмеження трафіку.
• Важливо впроваджувати та централізувати управління API. Це допомагає розробникам і командам безпеки відстежувати актуальні API та поточні версії специфікацій.
• Слід залучати команди інженерів для визначення безпечних стандартів написання коду, дизайну та розробки API. Це повинно включати архітектуру, патерни дизайну та засоби контролю безпеки.
• Без тестування ніколи не варто припускати, що автентифікація користувачів API буде опрацьована іншою системою. Дотримання таких принципів нульової довіри є особливо важливим у випадку багатошарових API.
• Потрібно включати API у процеси виявлення та тестування вебактивів. Це допомагає покращувати безпеку API як частину AppSec, а також інтегрувати її в життєвий цикл розробки програмного забезпечення (SDLC).
• Методи безпечного написання коду мають включати перевірку та очищення вхідних даних. Це особливо важливо для API, де захист ідентифікаторів об’єктів має вирішальне значення для запобігання вразливостям, пов’язаних з ними.
• Корисно впроваджувати тестування безпеки API у DevOps пайплайни, використовуючи інтеграції з інструментами розробки та системами відстеження помилок.

Створення безперервних процесів для безпеки вебдодатків і API

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

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