Привет, Хабр!
И снова в эфире Юрий Шабалин, главный архитектор компании Swordfish Security. Мы уже достаточно давно занимаемся консалтингом в области построения процессов безопасной разработки для своих клиентов. В процессе мы постоянно сталкиваемся с различными нюансами и сложностями при реализации практик DevSecOps. Ранее мы уже обсуждали SAST и OSA, а сегодня я бы хотел поговорить про практику автоматизированного динамического анализа приложений (DAST). А именно, какие подводные камни нас ждут при внедрении данной практики, какие особенности следует учитывать и как избежать проблем.
Ну что же, приступим.
Оглавление
Введение
DAST (Dynamic Application Security Testing)- это одна из практик безопасной разработки, в рамках которой выполняется автоматическое сканирование, имитирующее вредоносные внешние атаки с попытками эксплуатации распространенных уязвимостей. Чтобы обнаружить проблемы безопасности, средства DAST проверяют все точки доступа по HTTP, а также моделируют случайные действия и работу пользователей. В рамках данной практики происходит анализ уже развернутого и функционирующего приложения. Инструмент имитирует действия обычного пользователя: “ходит“ по Web-приложению, определяет, какие API есть у сервиса, отправляет специальным образом сформированные запросы. Например, подставляет во всевозможные места запроса различные неправильные данные (спецсимволы, кавычки, скобочки, разделители, переносы строк и т.д.). На основе анализа отправленного запроса и полученного ответа от сервера и их сравнения с обычным легитимным запросом происходит поиск уязвимостей. Инструмент динамического анализа отправляет и анализирует огромное количество запросов и может найти разнообразные проблемы безопасности, начиная от XSS, заканчивая RCE.
Основные параметры при выборе инструмента
Большинство сканеров имеет схожие возможности и принципы работы. Основными компонентами приличного сканера являются те, что перечислены ниже.
Во-первых, это “паук” (Spider) для составления карты приложения. Он обходит каждую ссылку на каждой странице (этот процесс называется crawling), до которой может дотянуться, нажимает кнопки, исследует содержимое файлов, которые могут дать ему дополнительные ссылки, а также по словарю перебирает потенциально возможные варианты названия страниц и директорий. Это позволяет оценить “поверхность атаки”, включая всевозможные точки взаимодействия с приложением - формы, открытые и скрытые поля ввода, параметры запросов, динамические элементы, особенности HTTP заголовков и т.п.
Сложность работы Spider-а заключается в том, что на странице может присутствовать динамически генерируемое содержимое (какие-нибудь AJAX-элементы, которые понятны пользователю, - ссылка или поле ввода), которое “пауки” не видят. Соответственно, если обход приложения был неполным и подобные элементы приложения в него не попали, - сильно падает количество уязвимостей, которые можно было бы обнаружить.
Второй составляющей сканера является “анализатор”. Это компонент, который обычно работает либо в пассивном, либо в активном режиме и занимается непосредственно анализом приложения. В первом случае анализатор работает только с данными, которые приходят к нему от “паука”, то есть анализирует ответы сервера о том, какая информация и какие заголовки в нем присутствуют, какие из обнаруженных ссылок потенциально могут содержать конфиденциальные данные (или доступ в запрещенные области приложения) и т.п. При этом сам инструмент никаких запросов не посылает и никак не работает с приложением.
В активном же режиме анализатор как раз начинает отправлять запросы с некорректными данными по тем точкам взаимодействия, которые обнаружил “паук”, а также по другим, вроде HTTP-заголовков или параметров, которые нигде на страницах не фигурируют, но могут использоваться в приложении (например параметр GET-запроса &isAdmin=true).
Дальше на основании ответов и реакции сервера анализатор делает вывод о наличии той или иной уязвимости. При этом обычно либо оценивается время ответа сервера в случае “правильных” и в случае “неправильных” данных, либо по шаблону ищется некоторая строка в тексте ответа.
Как уже ранее говорили, DAST - это практика, реализующая автоматический анализ приложения в динамике. Делается это при помощи различных инструментов, выбор которых должен основываться на вполне конкретных параметрах. Выделим часть из них и обсудим более подробно. Некоторые являются общими для всех инструментов, а другие применимы только для динамических сканеров, но тем не менее.
Качество сканирования
У любого инструмента основной характеристикой является качество сканирования. Иными словами, это соотношение выявленных уязвимостей к пропущенным. И также немаловажной частью являются ложные срабатывания, наличие которых существенно осложняет анализ и замусоривает результаты. А если их много, среди них могут затеряться реальные уязвимости.
Но возникает логичный вопрос, как провести подобный тест. В случае с ложными срабатываниями все достаточно просто: проанализировали отчет, разобрали срабатывания, понимаем, какая часть из них на самом деле ложные и не являются уязвимостями, и на основе этого примерно представляем, насколько инструмент “фолзит“. А вот для того, чтобы понять, какие проблемы безопасности пропустил сканер, нужно иметь представление о том, какие уязвимости вообще есть в приложении. Заранее это неизвестно. И есть несколько способов, как проверить сканер, а какой из них выбрать - зависит от вас.
Приведу несколько возможных кейсов:
В первом случае у нас есть наше приложение, в котором был обнаружен ряд уязвимостей (через баг-баунти, отчеты о тестировании на проникновение и т.д.). Главное, что у вас есть понимание, что проблемы есть, и вы знаете, где они находятся. Запуская сканер против этого приложения, мы пытаемся в его результатах найти эти срабатывания. Очень и очень хорошая практика, которая отлично демонстрирует качество сканирования инструментом именно ваших приложений и поддержку используемых в данном сервисе технологий. И при проведении такого эксперимента возникает понимание того, что используя автоматизированный инструмент можно было бы найти эти проблемы раньше, до выхода системы в промышленную эксплуатацию. К сожалению, далеко не у всех есть такие примеры и стенды (а даже если и есть, то не факт, что они еще работают из-за изменений в API или еще по каким-то причинам).
Во втором случае, нашего уязвимого приложения нет, но проверить работу инструмента как-то нужно. Тут на помощь могут прийти заранее уязвимые приложения, которые создаются (как правило) для обучения. На них можно поэкспериментировать с поиском проблем и их эксплуатацией. Небольшой совет: лучше выбирать не самые популярные приложения (вроде WebGoat), а что-то поинтереснее и поэкзотичнее (те, о которых вендор не догадывается). А то иногда кажется, что в некоторых инструментах прямо в коде стоит проверка
if page.title contains "WebGoat"...
В общем, найдите такое приложение, которое по стеку используемых технологий ближе всего к вашим разработкам. В конце статьи, в ссылках, будет несколько возможных примеров уязвимых Web-приложений, на которые можно обратить внимание и использовать их для тестирования.
Скорость сканирования
Скорость сканирования всегда имеет большое значение, особенно, если наши проверки интегрированы в процесс разработки. Ведь нередко бывает, что инструмент проводит тестирование, а пайплайн разработки ждет окончания сканирования. Это трата не только времени, но и денег. Конечно, это все регулируется и управляется способом интеграции и процессами внутри команд и стадии, на которой осуществляется проверка, но тем не менее, это немаловажный фактор. На самом деле, скорость сканирования очень сильно зависит и от самого анализируемого приложения, от того, насколько оно быстро отвечает на запросы, сколько одновременных подключений может обработать и т.д.
Так что в идеале, для сравнения скорости сканирования различных инструментов, нужно запускать их против одного и того же приложения в примерно одинаковых условиях. Если вы используете виртуализацию или контейнеризацию, то перед каждым новым инструментом можно для замера скорости поднимать новый инстанс с одинаковым количеством элементов внутри системы, при этом важно, чтобы сканеры были в равных начальных условиях. В моей практике был случай, когда мы тестировали инструменты один за одним, и каждый последующий показывал результаты по скорости все хуже и хуже. Как оказалось, во время предыдущих сканирований было создано огромное количество новых сущностей внутри приложения и оно стало куда как медленнее отвечать на запросы. Да, в случае обычного использования это было незаметно, но когда запросов десятки тысяч, каждая секунда промедления добавляла в итоговый результат свое значение, и это существенно замедляло сканирование.
Возможность детальной настройки
Каждый инструмент автоматического анализа должен иметь детальные настройки сканирования. Они позволяют не только улучшить качество процесса (указав инструменту, какие технологии используются, какие проверки актуальны), но и повысить скорость анализа, убрав лишние запросы и ограничив зону анализа. При этом, чем детальнее настройки и чем точнее мы можем сказать инструменту, что и как сканировать, тем лучше. Конечно, есть “умные“ и продвинутые решения, которые сами умеют себя подстраивать и определять различные параметры приложений. Это, конечно хорошо, но это не должно, на мой взгляд, отменять возможность детальной ручной настройки сканирования.
Ситуации бывают разные. Иногда нужно просканировать приложение в нескольких вариантах, начиная от полного тотального анализа, заканчивая легкой поверхностной проверкой, и возможность точечной настройки инструмента может оказаться очень кстати.
Обращать внимание стоит на количество параметров, которые позволяют настроить инструмент, а также на то, насколько легко их корректировать, как меняется время сканирования в зависимости от тех или иных настроек. Я бы порекомендовал сделать несколько “профилей“ сканирования: быстрый и поверхностный для начального анализа приложения, полный или максимальный - для полноценного, а потом сравнил бы эти режимы у различных вендоров. Поверьте, результаты тестирования в сравнении нескольких инструментов могут удивить.
Поддерживаемые технологии
Конечно, выбирать инструмент нужно исходя только из тех технологий, что используются в разработке в вашей компании. Для этого лучше всего провести небольшой анализ таких продуктов и составить перечень актуальных для вас технологий, фреймворков и языков. Перечень может получиться достаточно внушительный, особенно в больших компаниях, поэтому в качестве некоторого критерия оценки я бы выбрал несколько параметров.
Первое - это то, какое количество технологий и фреймворков, используемых у вас, покрывает инструмент. Ну например, мы применяем Angular, Vue.js и React для фронта и Python, PHP и .Net для бэкенд части во всех наших сервисах. А инструмент, который мы тестируем, поддерживает только Angular, React, Python и PHP (то есть, 4 из 6 технологий/языков).
Вторым параметром (и определяющим, на самом деле) может стать поддержка ключевых технологий или технологий, используемых в самых критичных и важных ваших сервисах. К примеру, основное ваше приложение написано на Angular+Java, а некоторый портал для заявок или лендинг на .Net. И тут фокус смещается на поддержку технологий именно для наиболее важного сервиса. Итак, определите список таких сервисов и отдельно проверьте непосредственно на них или похожих проектах, как инструмент динамического анализа себя показывает.
Поддерживаемые интеграции
Инструмент, который стоит отдельно от процесса и никак в него не интегрирован, практически бесполезен. Да, можно запускать периодические проверки и обрабатывать результаты, но желаемого эффекта это не принесет. Для того, чтобы практика динамического анализа (а на самом деле и любая другая), приносила максимум пользы и результатов, ее необходимо интегрировать в процесс разработки и запускать в определенные моменты сборки. Чтобы понять, насколько легко инструмент будет интегрироваться в вашу инфраструктуру, заранее составьте список того, что используется в процессе CI/CD, прикиньте примерный план того, как и когда будет запускаться инструмент. Все это позволит посмотреть на инструмент с точки зрения интеграций, насколько он вам подходит. Есть ли плагины или готовые примеры интеграций для ваших инструментов CI/CD, есть ли CLI у инструмента, насколько просто он интегрируется с различными системами сбора дефектов или оркестрации (DefectDojo, AppSec.Hub и т.д.), насколько хорошо описан API у инструмента. И на самом деле API - это, наверное, одна из самых главных вещей, поскольку в него все равно рано или поздно придется заглянуть и что-то автоматизировать.
В моей практике было несколько случаев, когда инструмент имел свои собственные плагины к Jenkins, но они оказались не очень удобными, хотелось большей свободы и кастомизации, поэтому пришлось написать собственную обвязку вокруг API. И лучше бы я этого не делал, так как седых волос у меня явно прибавилось, пока я пытался понять, как этот инструмент функционирует, почему примеры из документации не работают и по какой причине один и тот же токен в трех разных API возвращается и принимается в разных форматах (с разделителями, без разделителей, lowercase, uppercase и тд). После такого эксперимента хотелось разыскать автора этого API и что-то эмоциональное ему высказать, ведь работать с таким API очень сложно.
Так что оценивать нужно именно комплексно. Насколько инструмент хорошо умеет интегрироваться в ваши инструменты разработки и насколько удобно использовать его API, потому что рано или поздно он вам понадобится.
Типы и технологии записи последовательности логина
Очень важно для динамических сканеров то, насколько хорошо у них развита технология записи последовательности логина. Ведь самое интересное всегда скрыто за аутентификацией, и ее обязательно надо пройти, чтобы попасть внутрь приложения.
И тут также придется немного потрудиться и собрать среди всех сервисов все возможные варианты логина. Казалось бы, что сложного? Подставь в формочку правильные логин и пароль, получи сессию - и вперед, анализировать. Но как обычно, дьявол кроется в деталях. Под капотом аутентификации мы чего только не встречали. И хэширование пароля перед отправкой, и его шифрование общим ключом на фронте, и аутентификацию по сертификатам, и Kerberos, и чего только не было. А поддерживает ли инструмент весь этот зоопарк - вопрос хороший. Будет крайне обидно и неприятно выбрать решение, которое не может аутентифицироваться в части сервисов, потому что они не попали в зону тестирования. Поэтому соберите максимально разнообразные приложения для тестирования и проверьте на каждом из них, получится ли пройти в них этап логина.
Маленький совет, немного относящийся к предыдущему пункту про API и возможности интеграции. Некоторые инструменты поддерживают Upstream Proxy при сканировании. Такой подход может помочь, если ваше приложение использует что-то необычное в процессе аутентификации. К примеру, в одном случае нам пришлось поднимать Mitm Proxy, писать свой плагин для обработки запроса на логин, производить некоторые манипуляции с параметрами и передавать дальше в приложение, поскольку инструмент динамического анализа самостоятельно никак не мог повторить процесс аутентификации пользователя из-за специфики приложения. Да, пришлось подумать, покодить немного и чуть переделать процесс запуска сканирования, но в итоге мы успешно покрыли часть сервисов с более сложной аутентификацией. Но этого не получилось бы, если бы не исследованные ранее возможности по интеграции.
И сюда также относится момент, про который часто забывают (я тоже его забыл и добавил только когда перечитывал статью). Это про разлогинивание. В процессе сканирования отправляется много различных запросов и сервер на некоторые из них могут просто “выкинуть“ пользователя из системы. Инструмент динамического анализа обязательно должен это отловить и снова пройти процедуру “входа” в приложение, потому что дальнейшее сканирование не имеет большого смысла. Важно понимать, насколько гибкие условия могут быть для этого процесса и насколько точно инструмент может понять, что запросы больше не проходят (это может быть как код ответа сервера, так и сообщение в теле ответа, какой-то заголовок или его отсутствие и многое другое).
Роадмап развития инструмента
Технологии не стоят на месте: каждый день где-то в мире появляется новый JavaScript-фреймворк, и разработчики начинают хотеть переписать все на него. А потому скорость поддержки новых технологий, скорость реакции на новые вектора атак или паттерны различных уязвимостей - важные пункты при выборе инструмента. И здесь стоит обратить внимание на несколько вещей, о которых написано ниже.
Во-первых, это то, насколько часто выходят обновления инструмента или обновление сигнатур/паттернов или правил анализа. В некоторых случаях эти процессы разделены, то есть обновление функциональности продукта может выходить раз в три-четыре месяца, но обновления именно правил анализа и паттернов для определения известных уязвимостей могут появляться намного чаще. Посмотрите на сайте инструмента или запросите такую информацию у вендора. Это хорошо покажет, насколько разработчик следит за тенденциями и насколько у вас актуальна будет база проверок. Как вариант, оцените, насколько быстро каждый из вендоров в сравниваемых инструментах добавил паттерны и способ поиска уязвимости Log4Shell и, что более интересно, уязвимостей, менее нашумевших, но пришедших после того, как библиотека Log4j привлекла к себе внимание исследователей.
Во-вторых, уточните, насколько вы сможете влиять на развитие инструмента и как устроена работа с запросами на добавление функциональности. Это покажет, как быстро выйдет необходимый вам функционал в продукте. Если взять пример выше (из предыдущего пункта про аутентификацию), то как скоро вендор сможет доработать функциональность, чтобы продукт “из коробки“ мог аутентифицироваться в приложении с чуть более сложной логикой, чем отправка формы на сервер. И насколько удобно этот процесс устроен и не придется ли вам месяцами переписываться с вендором и напоминать ему о вашем запросе.
Качество составление карты приложения или краулинга
Если мы анализируем приложением “с нуля“, без дополнительной информации, то нужно понимать, насколько возможно собрать все пути и переходы в приложении, насколько точным будет “краулинг“ и что он покроет в результате. Этот параметр я бы отметил, как один из основных, так как качество сканирования напрямую зависит от него. Тут можно обратить внимание на настройки и способы получения информации. Умеет ли приложение не только мониторить запросы от FrontEnd к бэку, но и парсить, например, swagger или WSDL приложения. Может ли оно пытаться находить ссылки в HTML или JS и насколько качественно реализована поддержка SPA.
Еще одним хорошим моментом в этом функционале является процесс обогащения информации о приложении, то есть можно ли перед сканированием уточнить, какие именно API используются. Это может быть загрузка json-файла от Swagger или парсинг формата HTTP Archive (har), и многих других, которые так или иначе способны помочь инструменту максимально полноценно покрыть приложение проверками. Я бы посоветовал составить список того, что умеет импортировать каждый инструмент, и посмотреть, как это можно встроить в процесс. Одни из наших коллег подняли специальный Proxy-сервер и просили тестировщиков при осуществлении ручных тестов ходить через него, собирая тем самым все ссылки и функциональность, которая проходила тестирование. А в другом процессе в рамках автотестирования собирался har-архив, который автоматически загружался перед запуском сканирования, что тоже очень сильно помогало повысить процент покрытия приложения. Так что посмотрите в сторону отдела тестирования - возможно, они тоже смогут вам помочь определиться с тем, какие на какие интеграции обращать внимание в первую очередь.
Способы интеграции в процесс
Итак, инструменты мы долго тестировали и выбрали самый подходящий нам по ряду параметров. Следующий шаг (а вернее предыдущий, на этапе планирования и выбора, но это не так важно) - понять, как его можно встроить, в какие процессы и на каких этапах.
Согласно новой парадигме BSIMM - “Shift Everywhere“, все инструменты должны использоваться там, где они могут принести максимальную пользу. Исходя из этого, посмотрим, на каких этапах процесса разработки мы можем встроить динамический анализ.
Быстрый скан вместе с тестами перед Merge Request
В некоторых командах я встречал достаточно удобную вещь, когда при создании Pull Request (или по запросу разработчика) поднимался отдельный стенд из его ветки. Это позволяет достаточно оперативно тестировать изменения, смотреть, что все требования задачи выполнены, прогонять тесты перед слиянием с основной веткой и много других полезных вещей. При таком процессе помимо запуска обычных тестов можно предусмотреть и запуск инструмента динамического анализа, который по завершении работы выдаст разработчику отчет, содержащий описание выявленных уязвимостей. И, посмотрев на новые срабатывания, сразу можно их оперативно исправить, не дожидаясь сканирования на последующих этапах. Выше я уже говорил про возможность создания “легкой“ версии сканирования, при которой либо проверяются определенные точки API, которые указываются при запуске, либо просто идет более поверхностный анализ. Это может дать очень неплохой «выхлоп», особенно если сделать это удобно для разработчика и, например, нативно включить запуск динамического анализа в процесс запуска автотестов.
Результат в таком случае может быть представлен в виде отчета разработчику, который локально запускал тесты. В случае, если сканирование производится в рамках процесса Pull Request, можно напрямую писать в систему ревью кода комментарий с новыми выявленными срабатываниями. Да, из коробки это вряд ли будет работать в любом инструменте, но если приложить немного усилий и написать пару собственных обвязок вокруг запуска процесса сканирования, может выйти очень удобно.
После развертывания
Один из классических примеров использования инструментов динамического анализа. После того, как код собран, выложен в систему хранения версий и развернут на стендах начинается процесс автотестов. После их прохождения (успешного или неуспешного, тут уже зависит от тестов), запускается процесс динамического анализа приложения. Тут есть несколько нюансов, которые следует учитывать. Например, в идеале иметь собственный отдельный стенд для проверок безопасности. Против него также запускается ограниченный набор тестов после деплоя, чтобы понять, что сервер в принципе до сих пор жив, отвечает на стандартные запросы и ждет, пока его проверят. В таком подходе есть свои плюсы и минусы. Из плюсов это независимая среда, которую не страшно сломать или испортить кому-то результаты тестирования, это отдельные мощности, которые работают только для инструмента динамики, отдельные учетные записи, которые никто не поменяет внезапно и многое другое. Но с другой стороны, это лишние расходы на мощности и время на поддержания всего в работоспособном состоянии, да и иногда системы попадаются достаточно сложные, которые трудно развернуть отдельно и изолированно от других сервисов, и работают они только в интеграции друг с другом.
При любом раскладе, следует помнить одно правило: если у ресурса есть администраторский раздел, то его нужно тестировать только руками! В моем опыте есть одна история, когда мы не запретили инструменту ходить в админку и он удалил все данные, которые были нужны тестированию, насоздавал кучу лишнего, а после – просто уронил стенд. Ситуация была неприятная, но я хорошо запомнил, что тестирование админской части должно быть только ручным!
Перед переходом на препрод
В некоторых командах существует специальная среда, которая максимально повторяет продуктивную. Те же сервисы, похожие данные, обязательная работа не с заглушками (заранее подготовленными ответами сервера), а с полной интеграцией и другие вещи, позволяющие отловить различные ошибки, которые сложно было выявить на предыдущих этапах. И в части безопасности также необходимо использовать эту возможность и максимально (но без деструктивных действий), проверять систему динамическим анализатором. Да, это может занять намного больше времени, так как сканирование тут будет полноценное, без скидок и поблажек, но обычно это того стоит и эти результаты помогут понять, что все, что было исправлено на предыдущих этапах, что ничего нового реальные интеграции не принесли и в целом, быть уверенными, что система готова к выходу в промышленную среду в части безопасности.
Но тут важно правильно выбрать время и договориться со всеми, кто этот стенд также будет использовать, чтобы у вас не было пересечений и вы не мешали друг другу. Во-первых, полноценное сканирование может проходить достаточно долго и его можно запускать, например, вечером, когда никто со стендом особо не работает. Во-вторых, динамический анализ создает нагрузку на приложение, которое может повлиять на результаты нагрузочного тестирования, если они запускаются одновременно. Ну и конечно, не стоит забывать о тестировании функциональном, которому динамический анализ может очень сильно помешать и создать дополнительные сложности или неверные результаты тестирования.
Промышленная среда
Много споров ходит о том, нужно ли тестировать промышленную среду и если да, то как. На мой взгляд, сканировать приложение, которое уже находится в проме, нужно обязательно, но насколько глубоко, это вопрос хороший. Тут есть несколько стратегий, первая – это поверхностный скан без аутентификации, чтобы определить правильность конфигурирования серверов, заголовки и прочие вещи, которые часто забываются. Это обязательный «легкий» вариант сканирования, который всегда должен проводиться. Вторая стратегия - это некий средний режим сканирования, когда мы включаем все проверки, с перебором различных идентификаторов, брутфорсом доступных директорий и т.д., но не аутентифицируемся в приложении. То есть смотрим, что будет доступно злоумышленнику снаружи, без доступа внутрь системы. Тоже очень неплохой вариант для периодической проверки. Запуская такое сканирование, в одном из клиентов мы обнаружили, что на сервере выложены личные данные пользователей (сканы документов, договоров и т.д.), доступные без авторизации, просто по прямой ссылке. Конечно, на тестовых стендах такого не было, потому что эти данные лежали только на проме, но, не запустив подобную проверку, никогда бы и не узнали об этом.
Ну и третий вариант - это уже полноценное тестирование внутри приложения, с планомерным обходом всех доступных API и перебором всех параметров. Это самый сложный и опасный путь, и я не рекомендовал бы его использовать. Он может “выстрелить” в самый неподходящий момент и в неожиданных местах. Как было у меня, когда я поставил сканироваться сайт в промышленной сети из корпоративного WiFi, и IP-адрес, с которого шло сканирование, просто забанили. А в этот самый момент проходила демонстрация нового сайта для топ-менеджеров. И когда все попытались с корпоративных устройств из нашего WiFi зайти на сайт, они увидели вместо красивейшего нового сайта окошко «403 – доступ запрещен». Была крайне неприятная история, которая научила меня всегда согласовывать время проведения подобных мероприятий не только на тестовых серверах, но и на промышленных (скорее, особенно на промышленных). Так что не повторяйте, пожалуйста, моих ошибок и проводите тестирование только в специально отведенное для этого время.
Какие инструменты посмотреть
В недавнее время выбор инструментов был довольно обширным, это и Acunetix, Netsparker, Rapid7, Nessus, AppScan, WebInspect и другие вендоры, которые выпускали очень неплохие решения и могли похвастаться очень качественными результатами.
Однако, в свете недавних событий выбор инструментов для динамического анализа серьезно уменьшился, и теперь такого разнообразия уже не встретишь. Но хорошие решения все же остались. Часть из представленных ниже инструментов создана на базе OpenSource, часть - платные, коммерческие инструменты, но все их можно расширить и настроить, чтобы они подходили именно для вашего процесса и под ваши задачи.
OWASP ZAP (Zed Attack Proxy) — один из самых популярных в мире инструментов безопасности. Это часть сообщества OWASP, а значит, этот инструмент абсолютно бесплатный. Для него присутствуют различные SDK и API под разные языки программирования, есть возможность использовать плагины как собственной разработки, так и от сообщества. Можно запускать в различных режимах и управлять программно, что позволяет его интегрировать в процесс разработки, имеет плагины в различные CI/CD инструменты. Но у всего есть и обратная сторона медали: поскольку это Open Source, то качество сканирования, на мой взгляд, уступает энтерпрайз-решениям. Ну и функционал из коробки не сильно радует, хотя его можно неограниченно расширять и дописывать.
Продукт от компании PortSwigger, который в теории нацелен на энтерпрайз уровень, а именно предоставляет некоторый портал для настройки сканирований, полноценный REST API для взаимодействия и управления запуском сканирований, получением отчетов и многое другое. Сканирующим агентом выступает классический и привычный BurpSuite, запущенный в режиме headless, но с некоторыми ограничениями. Так, в него нельзя загружать свои плагины и взаимодействовать как-то иначе, чем через управляющие команды с головного портала. На тот момент, когда мы его тестировали, у него была весьма небогатая функциональность, особенно в части настройки логина в приложении. На мой взгляд, намного выгоднее использовать классический BurpSuite Pro, запущенный в headless-режиме, со своими плагинами, расширениями и модулем, который реализует REST API для управления сканированием. Конечно, над такой конфигурацией придется немного попотеть и все отладить и настроить, но результат может оказаться весьма неплохим, учитывая все разнообразие плагинов и возможностей этого инструмента.
Ну и наконец новый продукт от компании Positive Technologies, направленный на закрытие пустующей ниши в области динамического анализа. У компании давно реализовано облачное решение — PT BlackBox Scanner. В нем представлен полноценный REST API для управления процессом сканирований, есть все задатки для детальной настройки параметров анализа, обещаются и другие интересные вещи. В последнюю неделю августа вендор выпустит официальный релиз коробочной версии продукта. Нам уже удалось протестировать бета-версию до запуска, и можно сказать, что это очень неплохая замена зарубежным вендорам. Как только выйдет официальный релиз, мы дополнительно проведем его тестирование и полноценное сравнение с другими решениями и поделимся с вами результатами.
Выводы
При реализации любой из практик в процессе DevSecOps необходимо учитывать особенности и нюансы именно вашей компании и подбирать инструмент, руководствуясь вашими потребностями. У каждого продукта есть свои сильные и слабые стороны, но какой подойдет именно вам, определит только полноценное тестирование и пилотирование различных вариантов (которых, к сожалению, осталось не так много).
Я надеюсь, что наш опыт и небольшие советы помогут тем, кто столкнется с муками выбора и тестирования инструментов, и поможет сделать правильный выбор и полноценно провести анализ применимости инструментов и практики в целом.
Всем спасибо, до встречи в новых статьях!
