Є кілька причин, чому тема безпеки API з’являється все частіше з наближенням до кінця 2022 року.
Ще в липні 2021 року Gartner передбачив, що до 2022 року атаки на інтерфейс програмування додатків (API) стануть найпоширенішим вектором атак, що спричинить витік даних для корпоративних веб-додатків.
Чи була права аналітична фірма? Поки що рано знати напевно OWASP все ще підраховує результати.
Атаки API знову в новинах. Виявляється ймовірна точка входу для Порушення Optus був скромним REST API. І хтось злив усі дані, вкрадені з Злом Twitter — який також включав API.
Коли ми говоримо Безпека API, ми маємо на увазі заходи та методи, які ми використовуємо для захисту API та даних, які вони передають. Ми можемо турбуватися про несанкціонований доступ, негативну реакцію на DDoS (більш ніж один API впав і залишив базову систему повністю відкритою та абсолютно незахищеною) або інші зловмисні атаки.
Є мистецтво захисту API; щоб зробити це правильно, потрібні легкий дотик і делікатне поєднання технічних і організаційних навичок.
З технічної сторони ми розглядаємо такі заходи, як автентифікація та авторизація, шифрування, автоматичне тестування та моніторинг. З організаційної сторони вам потрібно точно знати, для кого в організаційній діаграмі призначений API, і відповідним чином налаштувати доступ. Для зовнішніх API вам потрібно знати, скільки даних має бути доступним для зовнішнього світу, і як ці дані потрібно обробляти та подавати.
Як захищені API?
Коли ви намагаєтеся захистити API своєї компанії, існує розумний порядок дій.
По-перше, знайдіть і каталогізуйте кожен API. Кількість компаній, які дійсно роблять це та оновлюють свій інвентар API, справді невелика. Зручність для розробників, швидка розробка веб-сайтів і все більший поштовх до об’єднаних служб сприяють тому, що таємничі API з’являються раптом без будь-якої структури обов’язкової реєстрації.
Щоб уникнути такого роду повзання API, кожен із них має бути зареєстрований централізовано з такою інформацією:
- ІМ'Я
- Інструменти та пакети, які використовуються для створення API
- Сервери, на яких він працює
- Сервіси, які покладаються на цей API
- Документація всіх допустимих способів використання та кодів помилок
- Типові показники ефективності
- Очікувані вікна безвідмовної роботи або простою
Уся ця інформація надходить у сховище, яким керує команда з кібербезпеки.
По-друге, налаштуйте безпеку та автоматизацію продуктивності для кожного API. Ось чому ви попросили надати всю цю інформацію, і саме так ви зберігаєте все в безпеці. Використовуючи дані, надані розробниками (і командою DevOps, веб-командою тощо), команда з кібербезпеки та/або тестування може створити автоматизацію, яка регулярно перевіряє API.
Функціональні тести важливі, оскільки вони переконуються, що все працює належним чином. Нефункціональні тести важливі, оскільки вони перевіряють надійність і безпеку API. Пам’ятайте, що API повинні безпечно виходити з ладу. Недостатньо знати, що людина впала — потрібно знати наслідки цієї невдачі.
Нарешті, додайте API до звичайного пакету запобігання загрозам. Якщо в будь-якому з інструментів або пакетів, які використовуються для створення API, виявиться помилка, вам потрібно знати. Якщо будь-який із протоколів, які він використовує, вважається небезпечним, коли ви виявляєте проблему, вам потрібно попросити команду вимкнути API, доки їх не можна буде перевірити та перебудувати.
Зробити ці речі один раз – чудово; Створення культури програмування та безпеки, яка дозволить вам підтримувати повністю каталогізовані та задокументовані API, є довгостроковою метою.
Особливі особливості поведінки API, на які слід звернути увагу
Під час тестування пера та захисту API одні методи більш корисні, ніж інші.
- Почніть з аналізу поведінки. Це перевіряє, чи відповідає реальність документації щодо рівня наданого доступу, використовуваних протоколів і портів, результатів успішних і невдалих запитів і того, що відбувається з системою в цілому, коли сам API перестає функціонувати.
- Далі — рівні обслуговування. Це стосується пріоритету самого процесу на сервері, обмеження швидкості для транзакційних API, мінімальних і максимальних параметрів затримки запиту та вікон доступності. Деякі з цих деталей важливі для запобігання (або притуплення) DDoS. Інші корисні для відстеження повільних витоків пам’яті чи проблем зі збиранням сміття, які можуть бути довгостроковою загрозою цілісності самого сервера.
- Проблеми автентифікації та санітарії говорити безпосередньо про рівень довіри користувачів API. Як і з будь-якою іншою службою, запити потрібно продезінфікувати, перш ніж їх прийняти. Це запобігає впровадженню коду, переповненню буфера тощо.
Потрібен певний рівень автентифікації за допомогою API, розроблених для конкретної бази користувачів. Однак це може стати складним. Федерація — це одна з проблем, з якою вам потрібно мати справу, визначаючи, які центральні сервери ідентифікації та автентифікації ви погоджуєтеся. Ви можете мати двофакторну автентифікацію для особливо чутливих або потужних API. І звичайно, сама автентифікація сьогодні не обов’язково є паролем; біометрія є дійсним способом відгородити API. Якщо коротко: застосовуйте стандарти, які вважаєте розумними, і регулярно перевіряйте встановлені вами обмеження.
Нарешті, шифрування та цифрові підписи мають бути частиною розмови. Якщо це в Інтернеті, то ми говоримо як мінімум про TLS (повторіть мантру: ми не відпочиваємо без TLS!). Інші інтерфейси також потребують шифрування, тому вибирайте протоколи з розумом. Пам’ятайте, що статичну інформацію, будь то база даних чи пул файлів десь, також потрібно зашифрувати. Ніде жодних плоских текстових файлів, якими б «невинними» вони не були; сіль і хаш повинні бути стандартними. Контрольні суми є обов’язковими під час надання або отримання файлів із відомими сутностями (розмір, вміст тощо).
Нарешті, керування ключами може бути складним. Не очікуйте, що кожен спеціаліст із DevOps матиме ідеальну реалізацію цифрового ключа, коли пристойна частина спеціалістів із кібербезпеки наполовину це робить. Коли сумніваєшся, поверніться до шпаргалки OWASP! Ось для чого він там.
Відповідь на атаку API
Основне правило таке: якщо ваш API виходить з ладу, закрийте доступ. За жодних обставин служби не повинні виходити з ладу у відкритому або доступному стані. Пам’ятайте про обмеження частоти та зберігайте повідомлення про помилки короткими та загальними. Не хвилюйтеся про медові горщики чи в’язниці API — турбуйтеся про виживання.
Спеціально розроблені API-атаки на індивідуальній основі потрібно розглядати як будь-які інші спроби злому. Незалежно від того, чи помітили ви спробу самостійно чи за допомогою аналізу AI/ML, дотримуйтесь стандартної процедури. Не обмежуйтесь, тому що це «просто» API.
Безпека API відокремлює посереднього CISO, який зосереджується виключно на інфраструктурі, від майстерного CISO, який справляється з реальними бізнес-загрозами та забезпечує виживання. Створіть систему безпеки API, створіть автоматизацію тестування багаторазового інтерфейсу та оновлюйте свій інвентар API.
