Всем привет! Меня зовут Владимир Исабеков, в Swordfish Security я занимаюсь динамическим анализом приложений (DAST, Dynamic Application Security Testing). В этой статье мы поговорим о ключевых недостатках DAST-тестирования и рассмотрим один из способов их устранения.

Содержание:

• Недостатки DAST

• Применение инструментации на практике

• Плюсы и минусы инструментации

Недостатки DAST

DAST — это один из подходов к обеспечению безопасности веб-приложений и ПО. В основном практика используется для обнаружения уязвимостей в работающем приложении. При этом методика включает в себя взаимодействие с продуктом с помощью различных тактик и техник. Несмотря на ощутимую пользу, которую приносит DAST-анализ, у этой практики есть и недостатки, способные влиять на эффективность и точность тестирования безопасности:

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

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

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

Применение инструментации на практике

Инструментация — это техника программирования, которая позволяет внедрять дополнительный код в приложение для получения информации о его работе. Встраивание этого кода может происходить на разных уровнях: начиная от аппаратуры и заканчивая операционной системой и приложением. Инструментация — крайне обширная область, существует множество видов этой техники. Она широко используется в разных сферах, например, для профилирования приложений, повышения безопасности и отладки.

Теперь давайте рассмотрим вышесказанное на примере. Допустим, у нас есть Java-приложение с заранее известной уязвимостью типа XXE. Протестируем его методом DAST с помощью инструмента BurpSuite Pro и посмотрим, какие ветки кода он проанализирует. Для сбора трассы воспользуемся Open Source библиотекой JavaCodeCoverage (JaCoCo), созданной для измерения покрытия кода Java-приложений тестами. Она позволяет определить, какой процент кода был выполнен во время запуска тестов и какие строки остались неиспользованными.

JaCoCo поддерживает различные форматы отчетов, включая HTML, XML и CSV, которые могут быть использованы для оценки качества тестирования и выявления уязвимых мест в коде приложения. Отчеты JaCoCo также можно связать с популярными средствами непрерывной интеграции, такими как Jenkins, Travis CI и другими. JaCoCo позволяет инструментировать приложение различными способами. Мы воспользуемся возможностью инструментации байт-кода на лету с помощью Java-агента. Этот механизм позволяет выполнять предварительную обработку в памяти всех файлов загружаемых классов, независимо от структуры приложения.

Запустим наше приложение с агентом JaCoCo:

java -javaagent:jacocoagent.jar=port=8092,output=tcpserver -jar lab-xxe.jar

Агент JaCoCo собирает информацию о выполнении и выдает ее по запросу или при выходе из JVM. Существует три различных режима вывода данных выполнения, которые указываются в параметре output:

*file: При завершении работы данные об исполнении записываются в файл, указанный в destfile параметре;

*tcpserver: Java-агент прослушивает входящие соединения на TCP-порте, указанном в параметрах address и port. Результаты работы агента записываются в это TCP-соединение.

*tcpclient: при запуске агент подключается к TCP-порту, указанному в параметрах address и port . Результаты работы агента отправляются в это TCP-соединение.

Теперь проведем DAST-тестирование уязвимого приложения с помощью инструмента BurpSuite Pro. Результаты анализа:

Как мы видим, BurpSuite Pro не смог выявить уязвимость.

Проверим, какие строки кода он смог задействовать в ходе тестирования. Для этого воспользуемся интерфейсом командной строки JaCoCo.

java -jar jacococli.jar dump --port 8092 --destfile dump.exec

Командой dump мы запросили данные выполнения от агента JaCoCo, работающего в режиме вывода tcpserver.

Вывод на консоль

[INFO] Connecting to localhost/127.0.0.1:8092.
[INFO] Writing execution data to /home/user/lab-xxe/target/dump.exec.

Для получения отчета еще раз воспользуемся интерфейсом командной строки JaCoCo.

java -jar jacococli.jar report dump.exec --classfiles /home/user/lab-xxe/target/classes --sourcefiles /home/user/lab-xxe/src/main/java --html /home/user/lab-xxe/target/tmp

Вывод на консоль

[INFO] Loading execution data file /home/user/lab-xxe/target/dump.exec.
[INFO] Analyzing 3 classes.

В документации JaCoCo более подробной расписаны параметры команд, советую ее почитать.
Теперь мы можем проверить директорию tmp в каталоге сборки проекта.

В ней находится отчет об анализе покрытия кода.

Открываем 'index.html' в браузере. Наблюдаем результат покрытия кода тестированием BurpSuite:

Как видно из отчетов JaCoCo, BurpSuite Pro не смог задействовать строки кода, в которых была уязвимость. Для сравнения, вид отчета покрытия кода после успешной эксплуатации уязвимости в приложении:

Плюсы и минусы инструментации

Как мы увидели, инструментация приложения способна помочь в выявлении участков поверхности атаки, не охваченных в ходе DAST-тестирования. Также этот процесс в случае эксплуатации уязвимости наглядно показывает слабое место в исходных текстах. Очевидно, что 100%-ное покрытие исходных текстов DAST-тестированием не гарантирует отсутствия уязвимостей, но как метрика качества может быть вполне полезна.

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