Введение
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. В этом разделе описаны передовые технические возможности для преодоления трудностей проверки 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. Организации все чаще приходят к осознанию того, что это должно быть обычной частью SDLC. Внедрение сканирования API в рабочие процессы разработки является логичным шагом, и Invicti сделали это частью централизованной и автоматизированной качественной AppSec-платформы.
Единственный способ гарантировать постоянную безопасность API, несмотря на все большую сложность и непрозрачность приложений – это упростить и централизовать все их проверки, включая API.
*Не всегда возможно получить полноценное доказательство через API и обозначить проблему как автоматически подтвержденную, но это не влияет на надежность результатов.
