Вступ
API (прикладні програмні інтерфейси) перетворилися з доповнень до основного застосунку в фундаментальні блоки сучасної архітектури програмного забезпечення. Вебдодатки, що складаються із сотень мікросервісів, покладаються на API для виконання функціонала бізнесу й обміну даними. З одного боку, це дає змогу різним командам швидко розробляти компоненти. Але з іншого, використання API надає доступ до внутрішнього вмісту додатка всьому світу, що робить ретельні перевірки безпеки більш важливими, ніж будь-коли.
Один ретельно розроблений запит API може надавати цінні дані, будучи більш прихованим за спроби входу вручну. Тому кіберзлочинці тепер регулярно включають API у свою сферу розвідки та атаки.
Без централізованого керування та належної перевірки незадокументовані API можуть бути запущені в продакшн, непомітно збільшуючи поверхню атаки.
Кожну кінцеву точку API необхідно перевіряти на вразливості незалежно від того, чи вона задокументована. Це стосується і будь-якої іншої частини додатка, аби вона не стала сліпою плямою безпеки.
Знайти спосіб для якісної перевірки безпеки вебдодатків на всій поверхні атаки, включаючи інтерфейс користувача та API, є непростим завданням. Ця публікація розглядає труднощі сканування API, технічні рішення та найкращі практики для якісного впровадження в сучасний пайплайн веброзробки.
Складнощі перевірки API
Напрочуд багато організацій ігнорують або недооцінюють API як частину поверхні атаки вебдодатків під час планування та виконання своїх AppSec-програм. Хоч і більшість компаній усвідомлює необхідність сканування API, існують деякі практичні проблеми, які потрібно розв’язати для його впровадження. Наприклад, AppSec-спеціалісти часто постають перед труднощами під час пошуку правильних інструментів і робочих процесів.
Термінологія: доступ до API чи доступ через API?
Будь-яке обговорення безпеки цієї технології слід починати з чітких визначень для уникнення плутанини. Суть API випливає з його назви: це інтерфейс для програмної взаємодії з додатком.
Існує два окремих рівні безпеки:
- Захист доступу до самого інтерфейсу: всі запити, що надходять до приватного API, повинні бути авторизовані перед відправкою до додатка. Зловмисники можуть намагатися зламати або обійти авторизацію для отримання доступу до API та надсилання запитів чи атак на застосунок.
- Захист доступу до додатка: убезпечення застосунку від вебатак, що надходять через API, інтерфейс користувача чи інші канали. Ця публікація зосереджена насамперед на цьому рівні.
Ознайомлення з перевіркою API
Залежно від поточного набору інструментів і стилю роботи, проведення перевірок API може викликати труднощі. Інтерфейс є абстрактним і заздалегідь визначеним способом доступу до певного застосунку, служби чи системи. Це ускладнює перевірку на вразливості на рівні коду, оскільки додаток може використовувати будь-яку кількість мов програмування та технологій для отримання та надсилання даних до інтерфейсу. Деякі кінцеві точки можуть здійснювати інші виклики API, або один API може бути поверх іншого для кращої сумісності.
Тому для сканування API як «чорних ящиків» потрібна технологія динамічного тестування безпеки. Також варто періодично проводити імітації атак на API, як і на інші компоненти середовища вебдодатка, але, крім того, величезний масштаб, складність і швидкість сучасної веброзробки потребують автоматичного сканера вразливостей.
Проте ще один інструмент означає додаткову роботу з інтеграції, а потім ще більше з керування новим джерелом звітів про безпеку. І це за умови високої якості сканера, який виявлятиме справжні вразливості, а не хибнопозитивні.
API – це лише ще один спосіб взаємодії з вебдодатком, тому його треба перевіряти на вразливості разом з рештою застосунку, в ідеалі за допомогою одних і тих самих інструментів і процесів. Таким чином можна зробити перевірки та виправлення простішими, але для цього потрібно подолати чимало перешкод.
Завдання #1: Приборкати шум
Команди безпеки додатків дуже добре знайомі з колосальним обсягом роботи. Великі організації можуть мати сотні, якщо не тисячі розробників, але лише кількох інженерів із безпеки. У менших компаніях – нерідко лише одного. Оскільки розрив у навичках кібербезпеки все ще великий, і ситуація навряд чи скоро покращиться, то сканування API додає ще більше роботи. Більш того, цей процес викликає багато практичних труднощів.
Існує декілька основних типів API. REST є найпопулярнішою архітектурою, але більш складні та старі бізнес-системи можуть послуговуватися SOAP. А сучасні додатки, що працюють з великими обсягами даних, схильні використовувати GraphQL. Тож перш ніж обирати спеціалізований інструмент для конкретного типу API, необхідно опитати всі команди розробників, аби довідатися, які вони розробляють, обслуговують або планують додати в майбутньому. Вірогідно, знадобиться підтримка більше одного типу API, а це може передбачати декілька різних інструментів для створення, інтеграції та керування.
Наступна складність полягає у форматах дефініцій API. Існує принаймні дюжина популярних варіантів (як-от Postman, OpenAPI, також відомого як Swagger, WADL і WSDL), а також декілька інших форматів експорту проксі, що можуть знадобитися у разі відсутності повних дефініцій. Аби зрозуміти, які саме потрібні, необхідно знову провести опитування. У підсумку, це передбачає декілька додаткових інструментів для обслуговування та роботи з різними форматами.
До обсягу задач також додається кількість кінцевих точок API та результатів перевірки для обробки. Навіть всього лише зовнішній REST API середнього розміру може передбачати кілька десятків додаткових URL-адрес для сканування. А якщо застосунок складається з сотні мікросервісів, то це ще стільки ж API для перевірки. Таких додатків може бути хоч десять, і при цьому кожен API передбачає декілька результатів сканування.
Без ретельного та централізованого підходу до перевірок буде накопичуватися додаткова робота, яка може перевантажити ресурси безпеки, що буде негативно впливати на захищеність організації.
Завдання #2: Знати, що перевіряти
Фундаментальна відмінність перевірки API порівняно з вебдодатками полягає в тому, що на ньому не можна безпосередньо провести кроулінг, як на вебсторінці – повністю охопити API можна лише за допомогою його дефініції, яку можна дізнатися в розробників. Оскільки API можуть швидко змінюватися, в ідеалі це треба робити перед кожною перевіркою. Це надто енерговитратно, особливо для великих організацій, що займаються розробкою.
Навіть якщо компанія може на це виділити ресурси та час, але в неї немає стандартизованих політик щодо API, вона буде мати справу з різними форматами, архітектурами та платформами, що зазвичай потребують декілька інструментів для імпорту та сканування. І навряд чи кожен API в середовищі буде відомий і задокументований, адже дуже легко створити «тимчасову» кінцеву точку API, що згодом перейде в продакшн без офіційного тестування чи документації.
Хоч їх можна виявити за допомогою аналізу вебтрафіку, це може бути лише тимчасовим заходом. Важливо знати актуальні дефініції всіх API, аби уникнути ризиків. Однак дуже мало організацій повністю документує всі свої кінцеві точки, тому інструменти перевірки безпеки повинні виявляти та сканувати в тому числі приховані API. Враховуючи швидкі темпи розробки та часті цикли релізів, а також потенційну невідповідність між змінами в бекенді API, фронтенді вебдодатків і мобільних застосунків, сканування потрібно проводити автоматично та безперервно, аби постаратися охопити всю поверхню атаки.
Завдання #3: Забезпечити максимальне охоплення та точні результати
Автентифікація є критично важливою для перевірки веббезпеки, передусім для бізнес-додатків, що майже не надають дані та функціонал неавтентифікованим користувачам. Це особливо стосується API, в якому неавтентифіковане сканування було б безглуздим. Але багато сканерів вразливостей зазвичай мають проблеми з автоматизованою автентифікацією навіть на сайтах, доступних користувачам. З огляду на це, деякі ставлять під сумнів можливість ретельної перевірки API.
Ці сумніви зростають через хибні уявлення про автоматичне сканування вразливостей загалом, які ґрунтуються на глибокій недовірі до застарілих сканерів, розроблених за часів статичних вебсайтів. Вони можуть проігнорувати величезну частину поверхні атаки сучасних вебдодатків, що використовують JavaScript, як-от SPA, в якому динамічно згенерований фронтенд комунікує з сервіс-орієнтованим бекендом через API. У сучасному світі організації також часто використовують багатофакторну автентифікацію (MFA), авторизацію та технологію єдиного входу (SSO). Тому сканер, що не може дати з цим раду робить мало корисного, і більш того – шкодить, надаючи помилкове почуття безпеки.
Щоб йти в ногу з вебвразливостями, вручну проводячи перевірки безпеки одразу після виявлення нових типів атак, потрібно багато часу. Створення, обслуговування та запуск автоматичних сканувань, що збалансовують продуктивність і точність, уже є достатньо складним у випадку з інтерактивними вебсайтами та додатками. API підіймає планку до рівня, коли мало які інструменти відповідають очікуванням – і це ще до оцінки практичності їх впровадження в поточну програму розробки.
Завдання #4: Йти в ногу з пайплайном
Залежно від розміру середовища додатка та розвиненості програми AppSec, кожне сканування може генерувати сотні звітів про вразливості. Саме по собі проведення перевірки не посилює безпеку. Для цього потрібно виявити та усунути реальні вразливості до їх потрапляння в продакшн. І від результатів сканування до виправлення потрібно пройти довгий шлях.
Перевірки безпеки зазвичай проводяться вручну. Це здебільшого пов’язано з недостатньою впевненістю в точності автоматизованих сканерів та обмеженими можливостями їх інтеграції. Перевантажені команди також повинні займатися подвійною перевіркою результатів сканування, аби виключити хибнопозитивні. А потім – вручну призначати розробникам недоліки, які потребують виправлення.
З API роботи стає ще більше. Всі ці додаткові перевірки безпеки не є проблемою для будь-якого більш-менш придатного сканера вразливостей, за умови, що він може отримати доступ до всіх цілей сканування. Але якщо включити API в перевірки безпеки додатків, то за одну ніч можна отримати подвійну або потрійну кількість звітів про вразливості, частина яких може бути помилковими спрацюваннями, які не можна надавати в пайплайн розробки для виправлення.
Крім того, без спеціальної інтеграції зі стандартними для індустрії системами відстеження помилок, платформами CI/CD і брандмауерами вебдодатків (WAF), що є складною роботою, організації змушені створювати власні рішення, об’єднуючи різні інструменти та формати. І залежно від конкретних продуктів і технологій, кінцевий результат може бути далеко не бездоганним, вносячи проблеми та затримки в оптимізовані робочі процеси розробників.
Як зробити сканування API на вразливості технічною реальністю?
Вирішальною передумовою для подолання всіх цих перешкод і плавного включення API в ширшу програму безпеки додатків є наявність технічних можливостей. Кінцеві точки API додають ще більше роботи в і без того нелегкий процес застосування патчів. Тому найбільш надійним способом максимально охопити поверхню атаки незалежно від її складності є динамічне тестування безпеки додатків (DAST).
Рішення Invicti, створене на базі високорозвинених і перевірених технологій сканування вразливостей, пропонує прагматичний підхід до безпеки вебдодатків і API, орієнтований на DAST. У цьому розділі описано передові технічні можливості, які лежать в основі рішення Invicti, для розв’язання проблем перевірки API.
Охоплення всіх основних типів API та форматів дефініцій
Уніфікований підхід до перевірки API починається з переліку його типів і кінцевих точок в конкретному середовищі вебдодатків і наявності необхідних технічних засобів. REST API є найпоширенішим типом інтерфейсу в сучасних вебзастосунках, особливо для комунікації легких мікросервісів. SOAP API все ще використовуються в багатьох фінансових системах та інших корпоративних додатках, що мають чіткі потреби щодо інтерфейсу та формату даних. Також існує відносно новий тип API – GraphQL. Він швидко набирає популярність, особливо серед застосунків, що мають справу з великим обсягом даних. Invicti охоплює всі ці основні типи API, разом із вбудованими перевірками безпеки та підтримкою різних способів імпорту та виявлення дефініцій API.
Імпорт дефініцій і схем
Раніше величезна кількість різних форматів дефініцій API була основною перешкодою для централізації перевірки їх безпеки, адже потребувала одразу декілька інструментів, що ускладнювало весь процес. Invicti має вбудовану підтримку 15 різних форматів, включаючи Postman, OpenAPI (Swagger), WADL, WSDL тощо. До них належать як фактичні формати специфікації API, так і інші популярні джерела дефініцій API, як-от файли проєктів і експорт CSV. У випадку з GraphQL, який зазвичай передбачає роботу з однією кінцевою точкою, можна імпортувати файл схеми даних або надати URL-адресу інтроспекції (для отримання інформації про типи запитів і синтаксис, які підтримує даний GraphQL API) (якщо таку функцію увімкнено), щоб Invicti міг автоматично вивчати структуру запиту.
Для кількох форматів можна отримати дефініцію у вигляді URL-адреси замість файлу. Це сприяє централізації та автоматизації перевірок безпеки, оскільки завжди можна завантажити поточну дефініцію API з попередньо визначеного місця та бути впевненим, що кожне сканування включає актуальну версію. А за допомогою додаткового скриптингу навіть можна автоматично запускати перевірку кожного разу, коли дефініція API оновлюється, аби підтримувати постійну безпеку.
Формати дефініцій API, що підтримуються Invicti
Виявлення додаткових кінцевих точок API
Надзвичайно важливо мати дефініції API, адже тут не допоможе кроулінг, як у випадку з вебдодатками – потрібно знати кінцеві точки та формати запитів. Однак можуть траплятися випадки, коли так чи інакше потрібно перевірити незадокументовані API. Для цього сканер Invicti автоматично імпортує всі підтримувані файли дефініцій, які він знаходить. Під час сканування вебсайтів і застосунків він перевіряє структуру URL-адрес, і якщо він помічає ту, що схожа на виклик API, він намагається знайти та перевірити його кінцеву точку. Це включає евристичне переписування URL для виявлення параметрів запиту та слабких місць, як це зробив би зловмисник.
Стандартним підходом до перевірки зовсім або частково не задокументованих API є налаштування проксі для моніторингу їх трафіку, аби виявити кінцеві точки та специфікації запитів. Це особливо корисно для сканування бекенду API та мобільних додатків. Invicti підтримує кілька популярних форматів експорту проксі, включаючи Fiddler і Burp, що надає можливість послуговуватися сесіями проксі як джерелом даних для дефініцій. Invicti Standard також постачається зі своїм внутрішнім проксі-сервером, тож його можна запускати в локальному середовищі для відстеження трафіку API для подальшого використання під час перевірки.
Автоматична автентифікація
Вона є необхідною передумовою для сканування API, оскільки сканер має отримати до нього доступ, перш ніж він зможе перевірити додаток. Invicti забезпечує підтримку популярних методів автентифікації API, включаючи базову автентифікацію HTTP, вебтокени JSON (JWT) і OAuth2. Завдяки останньому можна проводити сканування в середовищах єдиного входу, що викликає труднощі в менш просунутих сканерів.
Оскільки API все частіше зазнають атак, то для запобігання несанкціонованому доступу були розроблені додаткові засоби захисту, зокрема анти-CSRF токени та коди автентифікації повідомлень на основі хешування (HMAC). Це ще один камінь спотикання для менш просунутих сканерів. Але функція pre-request скриптингу від Invicti дає можливість легко кастомізувати запити сканера для включення цих додаткових кодів і токенів. Це можна зробити вручну або у випадку з експортом Postman API, що включає pre-request скрипти, Invicti може автоматично їх імпортувати разом із дефініціями API. Таким чином надається можливість перевірити всі свої API на вразливості за допомогою повної автентифікації, не вдаючись до незграбних і ризикованих обхідних шляхів, таких як вимикання захисних засобів перед запуском сканування.
Незмінна точність перевірок
Invicti використовує повний набір перевірок безпеки для тестування всієї поверхні атаки додатка на вразливості, охоплюючи як інтерфейси користувача, так і API. Технологія Proof-based сканування використовується для автоматичного підтвердження* можливості експлуатації переважної більшості вразливостей прямого впливу без ризику помилкових спрацювань. Завдяки достовірним результатам організації отримують надійні дані для автоматизації перевірки безпеки додатків на всіх етапах циклу розробки та усунення недоліків без проблем для робочого процесу.
Можливість довіряти результатам сканування та виправляти слабкі місця на їх основі, не стикаючись з помилковими спрацюваннями та трудомістким обміном інформацією з іншими командами, все ще є рідкістю для організацій. Сучасні гнучкі робочі процеси DevOps покладаються на автоматизацію всього, що можливо, під час розробки та тестування. Але розробники побоюються інструментів перевірки безпеки, які часто надають хибнопозитивні результати. Для якісного впровадження в пайплайн потрібне рішення, створене на основі багаторічних досліджень, розробки та вдосконалення, що містить перевірки, які знаходять баланс між точністю, продуктивністю та безпекою сканування.
Оптимізація AppSec за допомогою однієї централізованої платформи
Розглядаючи API як невід’ємну частину загальної поверхні вебатаки та скануючи їх на наявність вразливостей за допомогою однієї централізованої платформи, підхід Invicti спрощує програму AppSec. Організаціям, що використовують роз’єднані інструменти, важко охопити все своє середовище та стрімко посилювати безпеку. Додавання окремого процесу для перевірки API до і без того розгалуженого інструментарію може призвести до ще меншої захищеності.
Invicti надає цілісну картину щодо безпеки додатків за допомогою платформи на основі DAST, яка дозволяє перевіряти та захищати API як невід’ємну частину загальної поверхні атаки. Це може зменшити кількість спеціалізованих інструментів сканування у робочих процесах і дає можливість інженерам із безпеки та розробникам якісно працювати над виправленням недоліків. Використання DAST дозволяє підтримувати загальну видимість, в тому числі бекенду, завдяки функції інтерактивного тестування безпеки додатків (IAST) і аналізу програмних компонентів (SCA) в одній уніфікованій платформі. Це надає централізоване уявлення про стан веббезпеки API, вебсайтів і вебдодатків, у різних методологіях тестування та на всіх етапах циклу розробки ПЗ.
Рекомендації для впровадження сканування API в програму AppSec
Для високої ефективності без перевантаження команд безпеки та розробників, сканування API на вразливості має бути звичайною, ненав’язливою частиною загальної програми. Оскільки API змінюють і надають дефініції під час розробки, потрібно вбудувати їх автоматизовану перевірку в пайплайн для врахування всіх змін.
На основі сотень історій клієнтів і понад десяти років підтримки організацій у впровадженні перевірки безпеки додатків, Invicti підготували перелік найкращих практик для інтеграції сканування вразливостей API у ширшу програму AppSec.
Відстеження дефініцій API
Замість того, щоб шукати специфікації та документацію API щоразу перед проведенням сканування, можна заздалегідь витратити трохи часу на обговорення з керівниками розробки для погодження централізованого та автоматизованого процесу відстеження всіх дефініцій API в організації. На практиці це просто: потрібно додати скрипт до наявного коду для відображення всіх змін дефініцій API у попередньо визначених місцях. Потім можна використати функції Invicti для імпорту з URL-адреси або файлу, щоб отримати дані про нові кінцеві точки та просканувати їх (потенційно навіть за допомогою внутрішніх викликів API для автоматизації процесу). Це надає можливість завжди повністю автоматично перевіряти всі свої поточні API.
Інтеграція перевірки API з наявними інструментами
Розробники працюють найкраще, коли в системі відстеження проблем у них є коректні та зрозумілі тікети. Інтегрувавши сканування API в наявні інструменти розробки, можна автоматично створювати тікети на основі попередньо визначених рівнів серйозності, дозволяючи розробникам виправляти недоліки безпеки, як і будь-який інший тип бага. Завдяки інтеграції Proof-based сканування та системи відстеження проблем Invicti можна безпечно формувати правила для автоматизації лише підтверджених звітів про вразливості та надсилати їх безпосередньо розробникам разом із вказівками для усунення. Повторне сканування також може бути інкрементним для швидкого отримання результатів. І коли недолік позначено виправленим, Invicti може автоматично повторно перевірити певний вебресурс, аби переконатися, що вразливість справді усунуто.
Перевірка всіх кінцевих точок API в SDLC
Щоб не покладатися виключно на перевірки безпеки API вручну на останніх етапах циклу розробки, натомість можна скористатися інтегрованим підходом на основі DAST для запуску автоматичного сканування на декількох етапах пайплайна. Це дає змогу провести перевірку всієї поверхні атаки додатка на кожному етапі розробки, включно до продакшну. Завдяки охопленню інтерфейсів користувача та API за допомогою точного й автоматизованого сканування, можна встановити базовий рівень безпеки та підтримувати його незалежно від частих оновлень програмного забезпечення чи змін у ландшафті загроз. Крім того, є можливість додавати інші процеси для убезпечення додатків, потрібні для конкретного бізнес-середовища та програми AppSec, а також поєднувати ручні та автоматичні методи перевірки API.
Досягнення високого рівня безпеки
Замість того, щоб сприймати перевірку API як черговий процес для впровадження в інструментарій розробки та безпеки, варто думати про неї як про частину ширшої картини AppSec. Слід шукати способи для значного посилення безпеки, що не потребують тривалого розгортання та перевантаження команд незручними зовнішніми інструментами чи непотрібною ручною роботою.
Правильне налаштування початкової автентифікації та перевірки має ключове значення під час сканування вебдодатків, особливо API. Для помітного покращення стану безпеки навіть у комплексних середовищах Invicti пропонує покрокову адаптацію.
Спрощення та централізація AppSec для уникнення проблем з безпекою API
Прикладні програмні інтерфейси є важливими шлюзами сучасних вебдодатків і бекендів, тому перевірка безпеки застосунків не може бути повноцінною без API. Організації все частіше приходять до усвідомлення того, що це має бути звичайною частиною SDLC. Впровадження сканування API в робочі процеси розробки є логічним кроком, і Invicti зробили це частиною централізованої та автоматизованої якісної AppSec-платформи.
Єдиний спосіб гарантувати постійну безпеку API попри зростання складності та непрозорості середовищ додатків – це спростити та централізувати всі перевірки застосунків, включаючи API.
*Не завжди можливо отримати повноцінний доказ через API та технічно позначити проблему як автоматично підтверджену, але це не впливає на надійність результатів.
