Разница между SAST, DAST и IAST

SAST, DAST, IAST – три основные подходы проверки безопасности приложений, которые можно легко перепутать.

Они представляют целый спектр методов тестирования: от сканирования только запущенного приложения до исключительно исходного кода.

В этой публикации описан принцип работы, плюсы, минусы и разница между этими терминами.

icon problem

Динамическое тестирование безопасности приложений (DAST)

Проверка всего запущенного приложения, API или веб-среды и отслеживание рискованного поведения относится к динамическому тестированию безопасности приложений (DAST).

Этот подход также называют black-box тестированием, поскольку он не может «заглянуть» внутрь приложения.

DAST может проводиться вручную (тест на проникновение) или автоматически (сканирование уязвимостей).

Когда говорят об инструментах DAST, то обычно подразумевают автоматизированные сканеры в противовес тестированию безопасности вручную, хотя они часто являются частью инструментария пентестеров.

Инструменты DAST

Они работают по принципу имитации действий пользователей, ботов и внешних систем, которые взаимодействуют с веб-сайтами и приложениями. Современные сканеры уязвимостей имеют встроенный веб-браузер для загрузки страниц, выполнения тестов и отслеживания реакций, указывающих на уязвимость.

Поскольку эти инструменты разработаны для автоматизированного и автономного тестирования, они должны справляться с аутентификацией, CSRF-маркерами и другими механизмами для получения доступа и проверки веб-страниц и конечных точек API.

Из всех подходов тестирования безопасности приложений легче всего начать именно с DAST. В простом сценарии потребуется всего лишь ввести URL-адрес и нажать кнопку для запуска сканирования.

DAST также является наиболее универсальным подходом, ведь качественное решение способно охватывать как информационную безопасность (для сканирования своей организации), так и безопасность приложений (для проверки любых созданных компанией веб-приложений).

Пример: обнаружение уязвимости к SQL-инъекциям с помощью DAST

Когда сканер сообщает об уязвимости к SQL-инъекциям, это значит, что он успешно сподвиг приложение на выполнение определенных команд в базе данных.

В таком случае инструмент обычно отправляет отчет об уязвимой странице или конечной точке, а также об «атакованном» параметре.

Сканеры с автоматическими подтверждениями, как Invicti Enterprise, могут искать и предоставлять доказательства уязвимости: обычно это результат уникальной операции, выполненной базой данных.

Плюсы DAST

  • Обнаружение уязвимостей, которые можно эксплуатировать, а также неправильных конфигураций, заголовков безопасности и других проблем, которые можно заметить только при запуске.
  • Совместимость с различными технологиями позволяет тестировать приложения и API независимо от фреймворков и языков программирования.
  • Не нуждается в исходном коде для проверки – может сканировать все запущенные компоненты вне зависимости от их происхождения (включая динамические зависимости).

Минусы DAST

  • Необходимость запуска приложения для тестирования (даже если это минимальный прототип).
  • Охватывает только выполняемый при проверке код.
  • Локализация недостатков может быть менее точной, чем у других методов.

DAST в Invicti

Invicti – вендор инструментов DAST, предоставляющий AppSec-платформу на основе этого подхода.

Она также включает в себя обнаружение активов с возможностью применения IAST и динамического SCA (анализа программных компонентов).

Invicti Enterprise имеет более десяти лет опыта в устранении многих типичных недостатков DAST, в частности посредством Proof-based сканирования, что увеличивает доверие к отчетам об уязвимостях, обеспечивая точную локализацию проблем (часто вплоть до строки кода, в сочетании с Invicti IAST), и интеграцию в рабочие процессы разработки.

icon problem

Статическое тестирование безопасности приложений (SAST)

Статическое тестирование безопасности приложений (SAST) заключается в анализе исходного кода приложения для обнаружения потенциально опасных конструкций и потоков данных.

Этот подход также называют white-box тестированием, поскольку он имеет доступ к содержимому приложения.

SAST является наиболее распространенным методом проверки безопасности в процессе разработки и единственным, который можно применять до запуска прототипа (т.е. на ранних этапах или во время работы над изолированными компонентами).

Инструменты SAST

Существует много разных типов инструментов SAST, от простых плагинов для IDE (интегрированная среда разработки) для предупреждения о незащищенном синтаксисе до автономных анализаторов кода, которые проверяют репозитории и имитируют потоки данных.

Эти инструменты зависят от языка программирования, поскольку они анализируют исходный код. Поэтому для тестирования многоязычной базы кода часто требуется сразу несколько решений.

Поскольку они нацелены исключительно на код и не могут учитывать намерения разработчика, инструменты SAST обычно предоставляют только предупреждения и рекомендации, а не обязательные указания в отчетах об уязвимостях.

Хоть это и общепринятый недостаток, он может привести к игнорированию или выключению классов предупреждений разработчиками, ведь большинство из них, как правило, являются ложноположительными. Это создает риски, поскольку таким образом можно пропустить настоящую уязвимость. Кроме того, это делает результаты SAST малопригодными для автоматизированной обработки.

Пример: обнаружение уязвимости к SQL-инъекциям с помощью SAST

Когда SAST сообщает о такой уязвимости, он предупреждает о потенциально опасных входных данных при создании запроса в базу данных.

То есть инструмент находит код, который генерирует SQL-запрос, идентифицирует его входные данные и замечает, что они не обрабатываются безопасно, например с помощью кодирования, обхода изолирования или просто запросов с указанными параметрами.

Иными словами, инструмент предупреждает о потенциально опасном синтаксисе, но не гарантирует уязвимость приложения.

Плюсы SAST:

  • Проверка статического кода без запуска программы.
  • Простое подключение к IDE и другим инструментам в процессе разработки.
  • Возможность проверки всей базы кода, даже того, который на данный момент не используется.

Минусы SAST:

  • Не обнаруживает динамические уязвимости, неправильные конфигурации или другие проблемы, возникающие во время работы приложения.
  • Большое количество ошибочных срабатываний из-за отсутствия проверки возможности эксплуатации уязвимости.
  • Тестирование только собственного кода.
  • Потребность в отдельных инструментах для разных языков программирования.

Анализ программных компонентов (SCA)

SCA – это еще один подход к тестированию безопасности, работающий на уровне кода. В отличие от SAST он проверяет не работу кода, а его содержимое.

Большинство инструментов SCA направлены на обнаружение и формирование отчетов об open-source компонентах с известными уязвимостями. Некоторые из них проверяют, используются ли меньшие фрагменты open-source кода в базе.

icon problem

Интерактивное тестирование безопасности приложений (IAST)

Инструмент, который может «заглянуть» внутрь запущенного приложения, относится к подходу интерактивного тестирования безопасности приложений (IAST).

Его также называют gray-box тестированием (сочетание black-box и white-box, то есть DAST и SAST).

IAST обычно добавляет динамическую информацию к анализу кода или данные на уровне кода к динамическому тестированию. В обоих случаях он пытается устранить недостатки DAST и SAST.

Инструменты IAST

Они очень разнообразны: от плагинов и агентов сервера до автономных решений для анализа кода.

Некоторые из них нуждаются в инструментировании кода, где исходный код программы меняется с помощью команд отслеживания, которые отправляют информацию о работе приложения инструменту IAST.

Слово «интерактивное» в термине этого подхода может в некой мере вводить в заблуждение, потому что мало инструментов IAST действительно взаимодействует с приложением.

Плюсы и минусы IAST

  • В отличие от SAST, IAST может обнаруживать некоторые динамические проблемы безопасности и проверять возможность эксплуатации уязвимости.
  • А по сравнению с DAST, этот подход может лучше находить, а также демонстрировать недостатки в коде приложения.
  • Преимущества и недостатки конкретного инструмента IAST подобны DAST и SAST.
  • Основным минусом автономного IAST является ограниченный охват кода.

Пример: обнаружение уязвимости к SQL-инъекциям с помощью IAST

IAST предоставляет отчет о SQL-инъекции, который содержит информацию из сканера DAST и сервера. Следовательно, кроме конкретной страницы, параметра и (в случае с Invicti) данных подтверждения риска эксплуатации, он также демонстрирует конкретную строку кода, которая нуждается в исправлении и дополнительное доказательство того, как полезная нагрузка (т.е. введенный запрос) была принята и обработана приложением.

IAST в Invicti

В Invicti компонент IAST был специально разработан в качестве дополнения и усовершенствования основного сканера DAST.

Он имеет действительно интерактивный подход и устанавливается на веб-сервере или сервере приложения, не нуждаясь в инструментировании кода.

Агент работает в тандеме со сканером уязвимостей, предоставляя ему данные о работе приложения и информацию с сервера, например несвязанные файлы, недоступные кроулеру и динамическому SCA.

На данный момент IAST поддерживает следующие серверные технологии: PHP, Java, .NET, Node.js.

Самозащита программ во время выполнения (RASP)

RASP – несколько расширенная концепция IAST. Второй инструмент отслеживает работу приложения и сообщает о недостатках безопасности. А RASP делает почти то же самое, но отличие состоит в том, что он все время работает в продакшне, и вместо проверки результатов тестирования он отслеживает реальный трафик и операции для обнаружения и попытки остановки атак.

Какой подход выбрать?

Каждый метод тестирования имеет свои достоинства и недостатки, который зависят от конкретного инструмента. Любая комплексная программа безопасности приложений должна включать несколько типов тестирования для всестороннего обнаружения уязвимостей как можно раньше в процессе разработки.

В идеале нужно иметь:

  • DAST, наиболее универсальный подход, для охвата собственной среды приложений и включения проверки в SDLC;
  • SAST для выявления проблем на уровне кода до попадания в сборки;
  • SCA для гарантирования современности и безопасности зависимостей.

Для того чтобы идти в ногу с быстрыми процессами DevOps, нужна интеграция надежного и автоматизированного тестирования безопасности в пайплайн CI/CD и рабочие процессы цикла разработки ПО. Invicti расширяет основную функциональность DAST с помощью IAST, что позволяет достигать высокого уровня точности, автоматизации и качества указаний для исправления недостатков.

Подписаться на новости