OWASP ТОП-10 ризиків безпеки API у 2023 році

Використання API продовжує швидко зростати. Як наслідок, захист API має бути більш досконалим, ніж будь-коли.

ТОП-10 найбільш актуальних ризиків безпеки API у 2023 році

1. Некоректна авторизація на рівні об'єктів

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

Rapid7 рекомендує використовувати цей механізм авторизації в кожній функції, яка отримує клієнтське введення для доступу до об'єктів зі сховища даних. Як додатковий засіб посилення рекомендується використовувати криптографічно захищені випадкові значення GUID для ідентифікаторів посилань на об'єкти.

2. Некоректна автентифікація користувачів

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

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

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

3. Некоректна авторизація на рівні властивостей об'єкту

Пов'язана з авторизацією лише на рівні об'єкта, авторизація на рівні властивостей об'єкта - ще один метод контролю обмеження доступу до певних властивостей чи полів об'єкта. Ця категорія поєднує аспекти «надмірного розкриття даних» та «масового присвоєння», описані в документі 2019 OWASP API Security. Якщо кінцева точка API розкриває чутливі властивості об'єкта, які не повинні бути прочитані або змінені неавторизованим користувачем, вона вважається вразливою.

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

4. Необмежене споживання ресурсів

Використання ресурсів API відноситься до використання центрального процесора, пам'яті, сховища, мережі та постачальника послуг для API. Атаки типу «відмова в обслуговуванні» виникають внаслідок надмірного споживання цих ресурсів, що призводить до простоїв та збільшення вартості послуг.

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

Також мають бути впроваджені методи кодування, що обмежують споживання ресурсів. Обмежте кількість записів, що повертаються у відповідях API, з обережним використанням пейджингу, якщо це необхідно. Завантажені файли також повинні мати обмеження за розміром, щоб запобігти надмірному використанню сховища. Крім того, необхідно ретельно оцінювати продуктивність регулярних виразів та інших засобів обробки даних, щоб уникнути високого споживання ЦП та пам'яті.

5. Некоректна авторизація на рівні функцій

Відсутність перевірок авторизації в контролерах або функціях за кінцевими точками API стосується порушення авторизації на рівні функцій. Цей клас уразливостей дозволяє зловмисникам отримати доступ до несанкціонованої функціональності; для зміни методу HTTP з `GET` на `PUT` для зміни даних, які не повинні бути змінені, або для зміни рядка URL з `user` на `admin`. Належна перевірка авторизації може бути утруднена через складність контролера та велику кількість груп користувачів та ролей.

Комплексне моделювання загроз відносно архітектури та дизайну API має першорядне значення для запобігання цим уразливостям. Переконайтеся, що функціональність API ретельно структурована, а відповідні контролери виконують автентифікацію. Наприклад, вся функціональність у кінцевій точці `/api/v1/admin` повинна оброблятися класом контролера admin, який виконує сувору автентифікацію. Якщо є сумніви, доступ повинен бути заборонений за замовчуванням, а дозволи мають видаватися за необхідності.

6. Необмежений доступ до конфіденційних бізнес-потоків

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

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

7. Підробка запиту на стороні сервера

Уразливості підробки запитів на стороні сервера (SSRF) виникають, коли клієнт надає URL або інший віддалений ресурс як дані для API. В результаті створюється підроблений вихідний запит на цю URL-адресу від імені API. Такі вразливості часто зустрічаються в параметрах URL-адреси перенаправлення, веб-перехоплювачах, функціях вилучення файлів та попередньому перегляді URL-адрес.

SSRF може бути використаний зловмисниками у різний спосіб. Сучасне використання хмарних провайдерів та контейнерів розкриває URL метаданих екземпляра та внутрішні консолі управління, які можуть бути використані для витоку облікових даних та зловживання привілейованою функціональністю. Внутрішні мережеві виклики, такі як запити бекенд-сервісів до сервісів, навіть якщо вони захищені сервісними сітками та mTLS, можуть бути використані для отримання несподіваних результатів. Внутрішні репозиторії, інструменти збирання та інші внутрішні ресурси можуть бути об'єктом атак SSRF.

Rapid7 рекомендує перевіряти та санувати всі дані, що надаються клієнтом, щоб зменшити вразливість SSRF. При реалізації функціональності отримання ресурсів необхідно забезпечити строгий дозвільний список. Списки дозволів мають бути докладними, обмежуючи все, крім певних сервісів, URL, схем, портів та типів медіа. Якщо можливо, ізолюйте цю функціональність у контрольованому мережевому середовищі з ретельним моніторингом для запобігання зондуванню внутрішніх ресурсів.

8. Помилки налаштувань безпеки

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

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

9. Неналежне управління активами

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

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

10. Небезпечне використання API

З даними, отриманими від інших API, потрібно поводитися з обережністю, щоб запобігти непередбаченій поведінці. Сторонні API можуть бути скомпрометовані та використані для атак на інші API-сервіси. При роботі з даними з інших API слід враховувати такі атаки як ін'єкція SQL, ін'єкція XML External Entity, атаки десеріалізації та інші.

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

Звертайтеся за персональною консультацією стосовно рішень Rapid7 та з запитами на проведення пілотних проєктів – до фахівців Softprom. 

Softprom - Value Added Distributor компанії Rapid7.