Миф #1: DAST не находит уязвимостей
Самые первые инструменты DAST (в начале 2000-х годов) были созданы как помощь для мануального тестирования на статических страницах, а не как самостоятельные решения, поэтому они были разработаны с завышенными показателями (overreport), чтобы дать исследователю (pentester) приблизительное представление о том, что именно нужно исследовать.
Некоторые из этих ранних инструментов тестирования «black-box» стали коммерциализированными и закрепили ложное представление об ограничениях DAST, особенно в то время, когда веб-сайты и приложения стали более динамичными, а устаревшие инструменты едва функционировали.
Acunetix и Netsparker (теперь Invicti) были одними из первых специализированных сканеров веб-уязвимостей, которые работали полностью автоматически и предоставляли надежные и пригодные для использования результаты, а Invicti, опираясь на это наследие, предложил расширенные возможности сканирования, автоматизированную аутентификацию, проверку на основе доказательств, обнаружение и тестирование API (интерфейсов прикладного программирования) и т.д. Современные инструменты DAST могут исследовать всю поверхность веб атак, а затем проверять ее на наличие уязвимостей, которые можно использовать, а также выявлять устаревшие и уязвимые компоненты в приложениях и технологическом стеке (stack). Важно, что они сканируют и тестируют страницы, используя полностью встроенный движок браузера, поэтому если пользователь может открыть страницу, DAST может сканировать ее – одновременно сканируя вещи, к которым пользователь обычно не имеет доступа, например, API интерфейсы.
Миф #2: DAST дает только возможные и ложноположительные результаты
Разработанные для проверки относительно простых статических веб-страниц и обозначения всего, что может потребовать ручного исследования, эти ранние инструменты никогда не предназначались для автоматизации без предварительного просеивания результатов экспертом. Можно сказать, что устаревший DAST был намеренно создан для того, чтобы давать в основном ложноположительные результаты, но поскольку всего за несколько лет веб-приложения стали сложнее и многочисленнее, получение точных и автоматизированных результатов стало обязательным.
Эта предпосылка легла в основу proof-based scanning – идеи о том, что способ получить несомненно точные отчеты об уязвимостях заключается в том, что сканер DAST фактически использует уязвимость в системе безопасности и возвращает доказательства уязвимого поведения приложений. Этот подход лежит в основе всех методов и инструментов тестирования Invicti, от DAST и IAST до SCA и безопасности API во время выполнения, но для того, чтобы сделать это безопасно, эффективно и воспроизводимо, потребовалось более десяти лет непрерывных разработок и усовершенствований. Хотя это возможно только для проверок безопасности, которые выполняют тестовую полезную нагрузку и могут вызвать реакцию целевого приложения, такие же требования к точности применяются ко всем другим автоматизированным тестам, выполняемым инструментами Invicti, что делает отчеты об уязвимостях непосредственно пригодными для использования в задачах на исправление – и в конвейере разработки.
Миф #3: DAST нельзя использовать в конвейере разработки
В водопадном процессе разработки программного обеспечения традиционно все тестирование, от функциональности до тестирования безопасности, проводилось на этапе контроля качества после завершения разработки. С появлением DevOps большинство тестирований было в значительной степени автоматизировано и интегрировано в конвейер, но ранние сканеры DAST не были созданы для автоматизации или скорости. Эти инструменты все еще приходилось запускать вручную, а их результаты анализировали эксперты по безопасности, часто возвращаясь к разработчикам с непонятными вопросами и на поздней стадии, что требовало дорогостоящего и неприятного отслеживания по всему автоматизированному конвейеру.
В настоящее время организации могут использовать и используют DAST в своих DevOps-пайплайнах наряду с SAST и другими инструментами тестирования безопасности. Это правда, что для сканирования DAST требуется запущенное приложение, но это не всегда должна быть полная сборка или полное сканирование. С помощью таких инструментов, как Invicti, любой прототип, который можно запустить, уже можно проверить, а если в большом приложении обновляется только одна страница, можно запустить инкрементное сканирование только обновленной части. Сейчас также распространены контейнерные развертывания, где требование «runnable app» выполняется эффективно и автоматически. Благодаря надежным результатам и производительности сканирования, которая на порядок выше, чем у устаревших инструментов, хороший DAST незаменим в любом жизненном цикле разработки программного обеспечения (SDLC) для построения DevSecOps.
Миф #4: Имея SAST фирма в безопасности
В основном на рынке кибербезопасности все еще доминируют известные поставщики сетевой безопасности и SAST, поэтому многие организации считают, что DAST – это не очень важно.
На самом деле многие из этих поставщиков недооценили важность безопасности веб-приложений еще в начале 2010-х годов, когда мир начал переходить на веб-программное обеспечение и облачные технологии, поэтому сейчас они пытаются догнать DAST. Одним из заблуждений, подкрепленным требованиями комплаенса, которые конкретно указывают на анализ исходного кода, является то, что инструмент SAST – это все, что нужно для создания и выпуска безопасного программного обеспечения.
Использование статического анализа при разработке, является лучшей практикой, но этого недостаточно для того, чтобы обеспечить полное покрытие тестирования безопасности по всей поверхности вебатак. Это возникает из-за двух разных пониманий «покрытия». Тестирование в процессе разработки – это покрытие кода, то есть то, какая часть исходного кода приложения была протестирована, и это то, на что ссылается SAST-покрытие. Но исправное веб-приложение имеет гораздо большую поверхность для атак, чем просто сторонний код, протестированный с помощью SAST, поэтому покрытие DAST касается тестирования как можно большей части этой поверхности, охватывая проблемы выполнения, неправильные конфигурации, динамические зависимости, фреймворки, API и многое другое как в стороннем, так и в собственном коде.
SAST проверяет, безопасен ли исходный код. DAST проверяет, безопасно ли все приложение. Итак, нужны и DAST, и SAST, в идеале – на одной платформе.
Миф #5: Сетевой сканер также проводит пентестирование, поэтому не нужен DAST
Если ввести «онлайн сканер безопасности» в Интернете, поиск предоставит множество вариантов. Сетевой сканер и сканер веб-уязвимостей (DAST) – это разные инструменты для разных целей. Если вебсервер настроен правильно и безопасно, сетевой сканер отметит, что сайтом можно пользоваться. Вместе с тем, это не говорит ничего о том, уязвима ли страница клиентского портала к SQL-инъекциям или межсайтовому скриптингу (XSS), или одно из бизнес-приложений имеет SSRF-уязвимость в конечной точке /api-v2/users/.
С другой стороны, тестирование на проникновение обнаруживает те же типы проблем, что и DAST, но в другом масштабе и временном промежутке. Большинство пентестеров начинают работу с запуска качественного инструмента DAST, а затем проводят детальное исследование в поисках уязвимостей, которые можно использовать и о которых нужно сообщить.
С помощью хорошего инструмента DAST можно постоянно проводить автоматизированное динамическое тестирование безопасности в конвейере и в производстве, а экспертов привлекать только после того, как проверятся все результаты DAST. Таким образом, получается непрерывное покрытие тестирования и лучшая ценность от пентестирования, поскольку эксперты могут работать над более сложными уязвимостями.
Если все сделать правильно, DAST может служить фундаментальной частью всей программы безопасности приложений, покрывая реалистичную поверхность атаки, а также заполняя пробелы, оставленные SAST и тестированием на проникновение. И в отличие от SAST, который используется только в разработке, он может выполнять двойную функцию в AppSec и InfoSec, служа показателем реального состояния безопасности, особенно с такими функциями, как Predictive Risk Scoring от Invicti.
