Мы создаем множество сложных программных продуктов и требования безопасности кода становятся все актуальнее. Автоматизация везде, в том числе и в сфере безопасности: алгоритмы говорят нам, как писать код. Очень хочется иметь волшебный инструмент, который бы говорил, безопасен наш код или нет. Попробуем проверить, есть ли волшебная кнопка в мире DevSecOps. Для этого мы взяли несколько статических анализаторов кода (SAST), залили в них уязвимый код и посмотрели, что получилось на выходе. Как пелось в песне группы Технология, “Нажми на кнопку – получишь результат, и твоя мечта осуществится”.

О результатах эксперимента мы и поговорим далее.

Зачем это все?

Практики DevSecOps стремительно развиваются, много разговоров о Shift left (смещение вопросов, связанных с безопасностью, как можно ближе к началу разработки), культуре безопасной разработки и инструментах: многие уже прошли этап внедрения  практики управления уязвимостями в периметре безопасности и патч-менеджмент, но этого уже недостаточно. Поскольку наряду со стандартным софтом используются написанные специально под определённые задачи или кастомизированные приложения (вендорные решения или собственные разработки), такие программы стали часто использоваться злоумышленниками как точка входа, что делает необходимым поиск и устранение уязвимостей в собственном коде. Эту задачу решают инструменты анализа исходного кода на уязвимости.

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

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

Если Вам досталась задача выбрать самый лучший SAST для своей команды, то здесь вы не найдете универсального правильного ответа, так как эта задача сложная, многогранная и очень индивидуальная. Выбирая решение «под себя», мы решили для начала проверить работу SAST «из коробки», чтобы посмотреть, на что способны эти чуда чудные и что они могут дать нам полезного.

Общая информация о продуктах

Рынок инструментов безопасной разработки активно растет и развивается. В России сегмент SAST хорошо развит, на рынке присутствуют как отечественные вендоры, так и зарубежные. Среди российских участников рынка можно выделить: Positive Technologies; PVS-Studio; «Газинформсервис»; «Ростелеком-Солар»; ГК «Эшелон». Согласно отчету «Critical Capabilities for Application Security Testing» Gartner выделяет на мировом рынке следующих основных игроков: CAST; Checkmarx; Contrast Security; GitLab; HCL Software; Micro Focus; Onapsis; Rapid7; Synopsys; Veracode; WhiteHat Security.

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

• Micro Focus Fortify

• PT Application Inspector

• Solar appScreener

• Checkmarx CxSAST

Fortify

Fortify неоднократно менял владельца, в данный момент поддерживается компанией Micro Focus. Представляет довольно мощный инструмент анализа кода. Fortify Static Code Analyzer входит в составе более крупного решения Fortify. Способен определять причины уязвимостей, приоритезировать и давать рекомендации по исправлению кода.

Основные особенности:

• Снижение ложных срабатываний за счет использования алгоритмов машинного обучения

• Поддержка большого числа языков (более 27 основных языков), в том числе ABAP / BSP, ASP.NET, Python, Ruby

• Охват категорий уязвимостей, внесённых в OWASP Top 10 и SANS Top 25, соответствие стандартам DISA STIG, PCI DSS и другим.

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

PT Application Inspector

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

• генерирует эксплойты — безопасные, но эффективные тестовые запросы, которые помогают подтвердить или опровергнуть наличие уязвимости

• Отечественный, локализованный продукт

• Широкий набор поддерживаемых государственных стандартов

• Наличие сертификата ФСТЭК России

• Использование базы уязвимостей веб-приложений WASC и классификатора CWE

• Возможность визуализации программного кода

Solar AppScreener

Solar appScreener (до версии 3.0 — Solar inCode) работает полностью автоматически, анализируя исходного кода программы и её исполняемых файлов. При отсутствии исходного кода можно загрузить рабочие файлы мобильного или веб-приложения. Для мобильных приложений можно скопировать в сканер ссылку на страницу в Google Play или App Store.

• Декомпиляция приложений

• Большое число поддерживаемых языков программирования (36 языков)

• Легко интегрируется с Git и Subversion, VSC-хостингами GitLab GitHub и Bitbucket и другими

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

Checkmarx

Checkmarx CxSAST – чугунный эталон мира безопасности, позволяет в автоматическом режиме обнаруживать и идентифицировать уязвимости наиболее распространённых языков программирования. Кроме всего прочего позволяет визуализировать код в виде блок-схем маршрутов выполнения. По результатам сканирования выдаются рекомендации по исправлению проблем с привязкой к графической схеме, что очень удобно.

• Поддерживает большое число языков программирования (более 20)

• Интегрируется с различными средами разработки, серверами сборки, системами контроля версий и отслеживания ошибок

• Небольшой процент ложных срабатываний

• Визуализация кода

Методика тестирования

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

Для проверки качества анализа «из коробки» мы выбрали два приложения на языке Java.

• https://github.com/appsecco/dvja

• https://github.com/ScaleSec/vulnado

Данные приложения мы выбрали не случайно, они написаны на языке Java, который для нас является основным, также они содержат широкий спектр стандартных уязвимостей, с которыми должны справляться выбранные инструменты анализа кода.

Описание уязвимостей, присутствующих в выбранных приложениях

XSS

Довольно распространенная уязвимость, которую можно обнаружить на множестве веб-приложений. Ее суть довольно проста, злоумышленнику удается внедрить на страницу JavaScript-код, который не был предусмотрен разработчиками. Подробнее можно почитать тут.

Наличие известных уязвимых компонентов

Тут все просто, в приложении используется версия библиотеки с известными уязвимостями

OGNL Expression Injection

Инъекция кода OGNL. OGNL – язык, который позволяет манипулировать свойствам https://en.wikipedia.org/wiki/OGNL

SQL Injection

Всем знакомая SQL инъекция, подробнее https://ru.wikipedia.org/wiki/Внедрение_SQL-кода

Password in Configuration File

Небезопасное задание пароля в конфигурационном файле

Privacy Violation

Нарушение конфиденциальности, в данном случае запись в журнал логина и пароля

Log Forging

Подделка записи журнала

Command Injection

Инъекция в текст командной строки, подробнее тут.

Open redirect

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

Misconfiguraton

Ошибки в конфигурации приложения

XXE

XXE-атака, основанная на недостаточной проверке входящего XML-файла. Если система способна принимать данные в этом формате, злоумышленник может включить в передаваемый документ ссылку на внешние объекты или локальные ресурсы целевой системы.

Brocken Access control

Нарушенный контроль доступа, это дает злоумышленникам возможность получить доступ к конфиденциальным данным.

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

Итоговый рейтинг считали по следующей формуле:

Сравнение результатов прогонов

SonarQube не нашел ни одной уязвимости ни в одном проекте, что было ожидаемо. На сим закончим с ним и перейдем к коммерческим решениям.

Анализ приложения DVJA

На данном приложении хорошо проявил себя Fortify, так как он единственный нашел опасную уязвимость OGNL Expression Injection.

По результатам анализа Fortify был найден 81 недостаток приложения dvja. В категории Critical и High не было ложноположительных срабатываний.

Все 11 критических недостатков несли серьезную угрозу безопасности:

Command Injection он занес в категорию High:

AppScreener в итоге нашел 88 недостатков, но среди них не было найденных Fortify серьезной уязвимости OGNL Expression Injection, а также Command Injection, XSS в списке отсутствовали как класс. Также смутил алгоритм оценки критичности. Например, тот же Checkmarx позволяет выбирать способы выставления Severity на основе нескольких заложенных шаблонов: OWASP, PCI, FISMA, NIST. В данном случае  такой возможности мы не нашли.

Пароль в конфигурационном файле был главной проблемой приложения, по итогам анализа.

В отчете были и ложноположительные срабатывания. Анализатор ругался на Timing attack при сравнении пароля с его подтверждением:

PT Application Inspector выдал 56 недостатков. Он не нашел OGNL Expression Injection, но command injection успешно записал в критические. Он единственный обнаружил использование уязвимой версии JQuery, также нашел ненайденные другими анализаторами XSS. Ложноположительных срабатываний не было.

С Checkmarx оказалось не все так просто. В статистике мы увидели следующие цифры.

Дело в том, что он считает вектора атак и если у вас в коде есть одна SQL инъекция, но данная инъекция может быть использована из 8 разных мест, то он в итоги запишет 8. Вся эта информация представляется в виде графа, на котором отмечено. где вставить проверку будет наиболее эффективно. Это очень удобно и информативно.

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

Расстроило одно ложноположительное срабатывание. В SQL Injection он записал этот код:

После анализа отчетов всех анализаторов получилась следующая картина:

Анализ приложения Vulando

Снова Fortify показал себя с лучшей стороны.

Он нашел SQL Injection и Command Injection и записал их в критические

Остальные недочеты сводились к Unreleased Resource и Poor Error Handling:

AppScreener опять немного смутил расстановкой критичности, но две основные уязвимости он обнаружил, только записал Command Injection в Medium level. Не обошлось без ложных срабатываний, XSS в отчете не было.

PT Application Inspector также обнаружил две основные уязвимости (правда в отчете почему-то они были отображены как 4 разных), в остальном все свелось к Log Forging при выводе отладочной информации, XSS он не нашел.

Checkmarx показал себя с лучшей стороны. Основные уязвимости были найдены, XSS была проставлена высокая критичность, нареканий к его работе не было. Он единственный нашел отсутствие соли в хешах, а также неверное формирование времени жизни JWT. На данном приложении Checkmarx выглядел убедительнее всех остальных.

В итоге получили следующие результаты:

Заключение

Внедрение инструментов анализа уязвимостей на больших проектах - нетривиальная задача, требующая точной настройки именно под ваш проект и команду. Но в начале долгого пути будет полезным посмотреть именно сырое сравнение «из коробки», чтобы получить представление о работе инструментов, понять основные особенности. Чуда не случилось, у всех инструментов есть свои сильные и слабые стороны, все требуют «доработки напильником». 

Мы рассмотрели только один из параметров сравнения, но постоянная ежедневная работа с инструментом требует намного большего, чем чисто синтетический разовый прогон на простых приложениях. Мы прокатились пару кругов по Нюрбургрингу на четырех суперкарах мира статического анализа, в жизни может оказаться, что ездить каждый день на них по проселочной дороге не представляется возможным. Эффективность внедрения во многом зависит от культуры разработки на проекте и готовности DevOps. Без правильно выстроенного конвейера и процессов разработки любое внедренное средство будет стоять для галочки. Кто-то должен анализировать отчеты на постоянной основе, необходимо выделение роли security champion на проекте для разбора отчетов и постановки задач на исправления командам. Все рассмотренные средства позволяют проводить глубокую кастомизацию под свои нужды, а это также требует наличие специалистов. В любом случае, перед внедрением необходимо прежде всего набрать или обучить людей, которые будут работать над безопасностью кода. Можно обкатать процессы на open source решениях и только после того, как будет понимание потребностей и ограничений, смотреть в сторону коммерческих решений.

Если данная тема будет интересна читателям, мы проведем более детальный обзор каждого из инструментов, тем более что один из производителей изъявил готовность дать более глубокий анализ работы своего продукта. В следующей статье предлагается рассмотреть процесс онбординга (onboarding) для инструментов статического анализа, т.е. первичную настройку сканирования с указанием функций, принимающих данные от пользователя, и функций, производящих обработку этих данных. Показать взаимодействие специалиста ИБ с Security Champions из команды разработки при анализе отчетов. По задаче динамического анализа рассмотрим настройки процесса, покажем ввод данных по учеткам для тестирования сайта с использованием разных ролей. Опишем процесс настройки сканеров для проверки по веб-формам из сценария.