Оскільки прикладні програмні інтерфейси (API) забезпечують роботу всього, від мобільних додатків до критично важливих систем бекенду, забезпечення їх захищеності є дуже важливим. У цій публікації розглянуто ключові ознаки безпечних API та ефективні методи тестування.
Чому захист API є критично важливим
Прикладні програмні інтерфейси є основою сучасних додатків, що з’єднують мобільні застосунки, вебінтерфейси, сторонні інтеграції та хмарні сервіси. Але це створює ризики. Якщо API незахищений, він може стати прямою точкою входу для зловмисників. Наслідки можуть включати:
- Витоки даних: конфіденційні дані користувачів, фінансові записи або персональна інформація можуть бути викрадені.
- Ескалація привілеїв: зловмисники можуть використовувати вразливості, щоб видати себе за користувачів або отримати доступ до функцій адміністративного рівня.
- Перебої в обслуговуванні: погано захищені API можуть бути використані для здійснення атак типу «відмова в обслуговуванні» або запуску каскадних збоїв.
- Порушення відповідності: незахищені API можуть призвести до невідповідності стандартам, таким як GDPR, HIPAA або PCI-DSS, що загрожує штрафами та юридичними наслідками.
Чекліст безпеки API
Хоча жодна система ніколи не буває ідеально безпечною, добре розроблені прикладні програмні інтерфейси зменшують ризики.
Обов’язкова автентифікація
Безпечний API майже завжди вимагає автентифікації, навіть для API-інтерфейсів “лише для читання” (окрім навмисного запуску публічної служби). Будь-який прикладний програмний інтерфейс, який дозволяє несанкціонований доступ до конфіденційних даних або бізнес-логіки є червоним прапорцем. Автентифікація допомагає гарантувати, що лише авторизовані користувачі або служби можуть отримати доступ до функціональності API. До поширених методів належать OAuth 2.0, JWT (вебтокени JSON) та ключі API з обмеженими дозволами. Щоразу, коли використовуються токени або ключі, вони потребують безпечного зберігання та керування.
Використання виключно HTTPS
Транспортування трафіку через HTTPS з TLS (Transport Layer Security, безпека транспортного рівня) є базовою вимогою безпеки для API та додатків. Без цього конфіденційна інформація, що потенційно може включати облікові дані, токени та вхідні дані користувача, можуть бути перехоплені під час передачі та скомпрометовані. Де це можливо, API повинні використовувати HSTS для забезпечення HTTPS у всіх API-інтерфейсах та повністю відхиляти незашифровані запити, щоб усунути ризики.
Обмеження швидкості
Це важливий захист від brute-force, атак використання вкрадених облікових даних та зловживання функціональністю API. Безпечні прикладні програмні інтерфейси повинні визначати ліміти запитів для кожного користувача або токена та застосовувати політики експоненціального відхилення або блокування, коли їх перевищено. Це допомагає підтримувати доступність сервісу та захищати від атак типу «відмова в обслуговуванні» (DoS).
Ведення журналів аудиту
Безпечна екосистема API зберігає логи спроб автентифікації, доступу до ресурсів та інші схожі події. Журнали аудиту допомагають виявляти підозрілу поведінку та надавати інформацію у разі порушення. Для чутливих API журнали повинні бути незмінними, мати позначки часу та централізовано зберігатися з належним контролем доступу.
Як перевірити безпеку API
Навіть якщо компанія дотримується практик безпечного написання коду, щоб мінімізувати ризик вразливостей, та використовує захист під час виконання для зменшення спроб атак, тестування – єдиний спосіб перевірити, чи механізми безпеки API дійсно працюють належним чином. Воно має бути регулярним та багаторівневим.
Використання автоматизованих інструментів тестування безпеки API
За своєю природою API забезпечують уніфікований доступ до систем бекенду та додатків, що робить динамічне тестування (DAST, black-box) основним підходом до перевірки безпеки. Щоб зробити тестування невіддільною частиною розробки API та застосунків, варто почати з включення інструментів DAST у конвеєри DevOps.
Просунуті рішення DAST, як-от Invicti (раніше Netsparker), можуть сканувати API в режимі реального часу в середовищах виконання та реалістично імітувати поведінку зловмисників. Інструмент підтримує дефініції OpenAPI/Swagger та інші, декілька методів автентифікації (включаючи OAuth) та кастомні заголовки, що робить його придатним навіть для складних корпоративних середовищ у великих масштабах.
Виконання ручного тестування на проникнення
Досвідчений пентестер може виявляти такі проблеми, як неналежна авторизація на рівні функцій або шляхи ескалації привілеїв, які автоматизовані інструменти не можуть виявити. Це особливо важливо для API, де ролі, дозволи та бізнес-логіка з кількох систем можуть перетинатися та взаємодіяти неочікуваним чином, що іноді призводить до складних вразливостей, для виявлення та експлуатації яких потрібні людські знання та креативність.
Застосування керування доступом
Кожен API-інтерфейс повинен мати правила управління доступом. Нижче наведено перелік важливих характеристик:
- Тільки автентифіковані користувачі отримують доступ до захищених API-інтерфейсів
- Чутливі операції захищені від міжсайтової підробки запиту (CSRF) та атак повторного відтворення
- Користувачі можуть виконувати лише дії, дозволені їхньою роллю
- Рішення щодо доступу застосовуються на стороні сервера, а не на стороні клієнта
Чекліст оцінки безпеки
Безпека транспортного рівня
- Застосування HTTPS у всіх API-інтерфейсах
- Вимкнення підтримки застарілих версій TLS (будь-яких, старіших за 1.2)
- Використання надійних наборів шифрів та дійсних сертифікатів
- Впровадження HSTS (HTTP Strict Transport Security) для запобігання атакам зниження версії протоколу
Перевірка даних
- Очищення вхідних даних на стороні сервера (важливо ніколи не довіряти клієнту)
- Використання суворих перевірок типу вмісту (наприклад, застосування application/json, коли очікується тільки JSON)
- Перевірка формату, довжини та типу даних параметрів
- Застосування перевірки схеми (наприклад, JSON Schema), де це можливо
Обфускація повідомлень про помилки
- Уникання детальних повідомлень про помилки, які розкривають внутрішні структури (наприклад, схему бази даних)
- Використання загальних відповідей на помилки (наприклад, 401 Unauthorized, 403 Forbidden) без розкриття логіки API-інтерфейсу
- Моніторинг надмірного логування або режимів дебагу, які могли бути випадково увімкнені у продакшні
Висновок
Важливо перевіряти безпеку API за допомогою комплексного тестування. Починаючи з безпечного дизайну, належної автентифікації, безпеки транспортування, контролю доступу та аудиту, можна додати регулярне сканування DAST та ручне тестування, щоб значно зменшити ризик компрометації.
Як лідер у сфері безпеки додатків та API, DAST-рішення Invicti об’єднує виявлення прикладних програмних інтерфейсів, тестування з підтвердженням вразливостей та управління недоліками на єдиній платформі, що інтегрується у робочі процеси розробки та AppSec.
Якщо ви хочете отримати безоплатну тимчасову ліцензію для тестування рішення Invicti або демонстрацію, то зв’яжіться з нами через e-mail, або іншим зручним для вас способом.
