Как устранить пробелы в DAST-тестировании с помощью инструментации

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Всем привет! Меня зовут Владимир Исабеков, в 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-тестированием не гарантирует отсутствия уязвимостей, но как метрика качества может быть вполне полезна.

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

Источник: https://habr.com/ru/companies/swordfish_security/articles/745822/


Интересные статьи

Интересные статьи

Межсерверные (server-to-server или S2S) события позволяют отслеживать кастомные события и параметры через HTTP запросы. Они часто используются в мобильной атрибуции, например, в Appsflyer или в Adjust...
В этой статье рассказывается, как объединить CrowdSec и Docker Compose для защиты приложений, заключенных в контейнеры. Это позволит нам:• автоматически закрывать скомпрометированным IP-адресам доступ...
Электронная подпись документа без проблем. Подписать бесплатно без регистрации и СМС
Вместо введения В статье описывается исследование, проведенное с целью проверки утверждения центральной предельной теоремы о том, что сумма N независимых и одинаково распределенных случайных вел...
Введение Рендеринг 3D графики — непростое занятие, но крайне интересное и захватывающее. Эта статья для тех, кто только начинает знакомство с OpenGL или для тех кому интересно, как работают граф...