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

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

Обзор кода (code review) – один из самых старых и надежных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе чтения кода выявляются ошибки или участи кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Более подробно с методикой обзора кода можно познакомиться в замечательной книге Стива Макконнелла "Совершенный код" (Steve McConnell, "Code Complete") .

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

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

Задачи, решаемые программами статического анализа кода можно разделить на 3 категории:

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

Другие преимущества статического анализа кода:

Полное покрытие кода. Статические анализаторы проверяют даже те фрагменты кода, которые получают управление крайне редко. Такие участки кода, как правило, не удается протестировать другими методами. Это позволяет находить дефекты в обработчиках редких ситуаций, в обработчиках ошибок или в системе логирования.
Статический анализ не зависит от используемого компилятора и среды, в которой будет выполняться скомпилированная программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки неопределенного поведения . Такие ошибки могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода. Другой интересный пример скрытых ошибок приводится в статье "Перезаписывать память - зачем? ".
Можно легко и быстро обнаруживать опечатки и последствия использования Copy-Paste . Как правило, нахождение этих ошибок другими способами является кране неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида "strcmp(A, A)". Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Недостатки статического анализа кода

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

Ошибки, обнаруживаемые статическими анализаторами весьма разнообразны. Вот, например, список диагностик , которые реализованы в инструменте PVS-Studio. Некоторые анализаторы специализируются на определенной области или типах дефектов. Другие, поддерживают определенные стандарты кодирование, например MISRA-C:1998, MISRA-C:2004, Sutter-Alexandrescu Rules, Meyers-Klaus Rules и так далее.

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

Доработка бизнес-приложений мировых разработчиков (CRM, ERP, биллинг и др.) с учётом особенностей и специфических требований рабочих процессов компании и разработка собственных бизнес-приложений с нуля — стандарт для российских предприятий. При этом в процессе внедрения и эксплуатации бизнес-приложений возникают угрозы информационной безопасности, связанные с ошибками программирования (переполнение буфера, неинициализированные переменные и др.) и наличием функций, которые приводят к обходу встроенных механизмов защиты. Такие функции встраиваются на этапе тестирования и отладки приложения, но по причине отсутствия процедур контроля безопасности кода остаются в рабочей версии бизнес-приложения. Также нельзя гарантировать, что на этапе создания бизнес-приложения разработчики умышленно не встроят дополнительный код, приводящий к наличию недекларированных возможностей (программных закладок).

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

ЭЛВИС-ПЛЮС предлагает систему анализа исходных кодов на основе продуктов мирового лидера в этой области — HP Fortify Static Code Analyzer (SCA) , а также российских компаний — InfoWatch Appercut и Positive Technologies Application Inspector .

Цели создания Системы

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

Задачи, решаемые Системой

Статистический анализ программного обеспечения на наличие ошибок/уязвимостей, производимый без выполнения приложений на уровне исходных кодов.
Динамический анализ программного обеспечения на наличие ошибок/уязвимостей, производимый после сборки и запуска приложения.
Реализация технологий безопасной разработки бизнес-приложений во время создания и на протяжении всего жизненного цикла приложения путем встраивания Системы в среду разработки приложений.

Архитектура и основные функции системы (на примере продукта HP Fortify SCA)

Статический анализ, также известный как статическое тестирование безопасности приложений (SAST - Static Application Security Testing):

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

Динамический анализ, также известный как динамическое тестирование безопасности приложений (DAST - Dynamic Application Security Testing):

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

Система на базе HP Fortify Software Security Center позволяет реализовать автоматизированные процессы обнаружения, приоритизации, устранения, отслеживания, проверки и управления уязвимостями в ПО бизнес-приложений. Инструменты HP Fortify могут встраиваться в интегрированные среды разработки (IDE - Integrated Development Environment), средства контроля качества (QA - Quality assurance) и системы отслеживания ошибок.

Основные функции Системы

Внедрение и автоматизация процесса обнаружения уязвимостей прикладного ПО (ППО) на различных стадиях разработки (создание, отладка, тестирование, эксплуатация, модификация).
Обнаружение уязвимостей в развернутых веб-приложениях на различных стадиях разработки ППО (создание, отладка, тестирование, эксплуатация, модификация).
Настройка условий и критериев обнаружения уязвимостей в ППО.
Поддержка современных языков программирования для определения угроз безопасности ППО (C/C++, Java, JSP, ASP, .NET, JavaScript, PHP, COBOL, PL/SQL, ABAP, VB6 и др.).
Поддержка различных инструментов разработки для интеграции со средой разработки ППО.
Формирование отчётов о проблемах безопасности проверяемого ППО с ранжированием найденных уязвимостей по степени риска.
Отправка практических рекомендаций по устранению обнаруженных уязвимостей в коде в среду разработки ППО.
Обновление базы уязвимостей для определения актуальных угроз безопасности ППО на основе предоставляемой вендором информации.

Преимущества от внедрения Системы

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

У каждого из команды ][ - свои предпочтения по части софта и утилит для
пентеста. Посовещавшись, мы выяснили: выбор так разнится, что можно составить
настоящий джентльменский набор из проверенных программ. На том и решили. Чтобы
не делать сборную солянку, весь список разбит на темы. Сегодня мы разберем
статические анализаторы кода для поиска уязвимостей в приложениях, когда на
руках – их исходники.

Наличие исходных кодов программы существенно упрощает поиск уязвимостей.
Вместо того чтобы вслепую манипулировать различными параметрами, которые
передаются приложению, куда проще посмотреть в сорцах, каким образом она их
обрабатывает. Скажем, если данные от пользователя передаются без проверок и
преобразований, доходят до SQL-запроса – имеем уязвимость типа SQL injection.
Если они добираются до вывода в HTML-код – получаем классический XSS. От
статического сканера требуется четко обнаруживать такие ситуации, но, к
сожалению, выполнить это не всегда так просто как кажется.

Современные компиляторы

Может показаться забавным, но одними из самых эффективных анализаторов
кода являются сами компиляторы. Конечно, предназначены они совсем для
другого, но в качестве бонуса каждый из них предлагает неплохой верификатор
исходников, способный обнаружить большое количество ошибок. Почему же он не
спасает? Изначально настройки такой верификации кода выставлены достаточно
лояльно: в результате, чтобы не смущать программиста, компилятор начинает
ругаться только в случае самых серьезных косяков. А вот и зря - если поставить
уровень предупреждений повыше, вполне реально откопать немало сомнительных мест
в коде. Выглядит это примерно следующим образом. Скажем, в коде есть отсутствие
проверки на длину строки перед копированием ее в буфер. Сканер находит функцию,
копирующую строку (или ее фрагмент) в буфер фиксированного размера без
предварительной проверки ее длины. Он прослеживает траекторию передачи
аргументов: от входных данных до уязвимой функции и смотрит: возможно ли
подобрать такую длину строки, которая бы вызывала переполнение в уязвимой
функции и не отсекалась бы предшествующими ей проверками. В случае если такой
проверки нет, находим практически 100% переполнение буфера. Главная сложность в
использовании для проверки компилятора - заставить его "проглотить" чужой код.
Если ты хоть раз пытался скомпилировать приложение из исходников, то знаешь,
насколько сложно удовлетворить все зависимости, особенно в больших проектах. Но
результат стоит того! Тем более, помимо компилятора в мощные IDE встроены и
некоторые другие средства для анализа кода . К примеру, на следующий
участок кода в Visual Studio будет выдано предупреждение об использовании в
цикле функции _alloca, что может быстро переполнить стек:

char *b;
do {
b = (char*)_alloca(9)
} while(1)

В этом заслуга статического анализатора PREfast. Подобно FxCop,
предназначенной для анализа управляемого кода, PREfast изначально
распространялся в виде отдельной утилиты и лишь позже стал частью Visual Studio.

RATS - Rough Auditing Tool for Security

Сайт: www.securesoftware.com
Лицензия: GNU GPL
Платформа: Unix, Windows
Языки: С++, PHP, Python, Ruby

Ошибка ошибке - рознь. Часть тех огрех, которые допускают программисты,
некритична и грозит только нестабильностью программы. Другие, напротив,
позволяют инжектировать шелл-код и выполнять произвольные команды на удаленном
сервере. Особый риск в коде представляют команды, позволяющие выполнить buffer
overflow и другие похожие типы атак. Таких команд очень много, в случае с C/C++
это функции для работы со строками (xstrcpy(), strcat(), gets(), sprintf(),
printf(), snprintf(), syslog()), системные команды (access(), chown(), chgrp(),
chmod(), tmpfile(), tmpnam(), tempnam(), mktemp()), а также команды системных
вызовов (exec(), system(), popen()). Вручную исследовать весь код (особенно,
если он состоит из нескольких тысяч строк) довольно утомительно. А значит, можно
без труда проглядеть передачу какой-нибудь функции непроверенных параметров.
Значительно облегчить задачу могут специальные средства для аудита, в том числе,
известная утилита RATS (Rough Auditing Tool for Security ) от
известной компании Fortify. Она не только успешно справится с обработкой кода,
написанного на C/C++, но сможет обработать еще и скрипты на Perl, PHP и Python.
В базе утилиты находится внушающая подборка с детальным описанием проблемных
мест в коде. С помощью анализатора она обработает скормленный ей сорец и
попытается выявить баги, после чего выдаст информацию о найденных недочетах.
RATS работает через командную строку, как под Windows, так и *nix-системами.

Yasca

Сайт: www.yasca.org
Лицензия: Open Source
Платформа: Unix, Windows
Языки: С++, Java, .NET, ASP, Perl, PHP, Python и другие.

Yasca так же, как и RATS не нуждается в установке, при этом имеет не
только консольный интерфейс, но и простенький GUI. Разработчики рекомендуют
запускать утилиту через консоль - мол, так возможностей больше. Забавно, что
движок Yasca написан на PHP 5.2.5, причем интерпретатор (в самом урезанном
варианте) лежит в одной из подпапок архива с программой. Вся программа логически
состоит из фронт-енда, набора сканирующих плагинов, генератора отчета и
собственно движка, который заставляет все шестеренки вращаться вместе. Плагины
свалены в директорию plugins - туда же нужно устанавливать и дополнительные
аддоны. Важный момент! Трое из стандартных плагинов, которые входят в состав
Yasca , имеют неприятные зависимости. JLint, который сканирует Java"овские
.class-файлы, требует наличия jlint.exe в директории resource/utility. Второй
плагин - antiC, используемый для анализа сорцов Java и C/C++, требует antic.exe
в той же директории. А для работы PMD, который обрабатывает Java-код, необходима
установленная в системе Java JRE 1.4 или выше. Проверить правильность установки
можно, набрав команду "yasca ./resources/test/". Как выглядит сканирование?
Обработав скормленные программе сорцы, Yasca выдает результат в виде
специального отчета. Например, один из стандартных плагинов GREP позволяет с
помощью паттернов, описанных в.grep файлах, указать уязвимые конструкции и
легко выявлять целый ряд уязвимостей. Набор таких паттернов уже включен в
программу: для поиска слабого шифрования, авторизации по "пароль равен логину",
возможные SQL-инъекции и много чего еще. Когда же в отчете захочется увидеть
более детальную информации, не поленись установить дополнительные плагины. Чего
стоит одно то, что с их помощью можно дополнительно просканировать код на на
.NET (VB.NET, C#, ASP.NET), PHP, ColdFusion, COBOL, HTML, JavaScript, CSS,
Visual Basic, ASP, Python, Perl.

Cppcheck

Сайт:
Лицензия: Open Source
Платформа: Unix, Windows
Языки: С++

Разработчики Cppcheck решили не разбрасываться по мелочам, а потому
отлавливают только строго определенные категории багов и только в коде на С++.
Не жди, что программа продублирует предупреждения компилятора - он обойдется без
суфлера. Поэтому не поленись поставить для компилятора максимальный уровень
предупреждений, а с помощью Cppcheck проверь наличие утечек памяти, нарушений
операций allocation-deallocation, различных переполнений буфера, использования
устаревших функций и многого другого. Важная деталь: разработчики Cppcheck
постарались свести количество ложных срабатываний к минимуму. Поэтому, если
прога фиксирует ошибку, можно с большой вероятностью сказать: "Она действительно
есть!" Запустить анализ можно как из-под консоли, так и с помощью приятного
GUI-интерфейса, написанного на Qt и работающего под любой платформой.

graudit

Сайт:
www.justanotherhacker.com/projects/graudit.html
Лицензия: Open Source
Платформа: Unix, Windows
Языки: C++, PHP, Python, Perl

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

graudit /path/to/scan

Наградой за старание будет цветастый отчет о потенциально эксплуатируемых
местах в коде. Надо сказать, что, помимо самого скрипта (а это всего 100 строчек
кода на Bash), ценность представляют сигнатурные базы, в которых собраны
регекспы и названия потенциально уязвимых функций в разных языках. По умолчанию
включены базы для Python, Perl, PHP, C++ - можно взять файлы из папки signatures
и использовать в своих собственных разработках.

SWAAT

Сайт: www.owasp.org
Лицензия: Open Source
Платформа: Unix, Windows
Языки: Java, JSP, ASP .Net, PHP

Если в graudit для задания сигнатуры уязвимости используются текстовые файлы,
то в SWAAT – более прогрессивный подход с помощью XML-файлов. Вот так
выглядит типичная сигнатура:

vuln match - регулярное выражение для поиска;
type - указывает на тип уязвимости:
severity - обозначает уровень риска (high, medium или low)
alt - альтернативный вариант кода для решения проблемы

SWAAT считывает базу сигнатур и с ее помощью пытается найти проблемные
участки кода в исходниках на Java, JSP, ASP .Net, и PHP. База постоянно
пополняется и помимо списка "опасных" функций, сюда включены типичные ошибки в
использовании форматирования строк и составлении SQL-запросов. Примечательно,
что прога написана на C#, однако отлично работает и под никсами, благодаря
проекту Mono - открытой реализации платформы.Net.

PHP Bug Scanner

Сайт:
raz0r.name/releases/php-bug-scanner
Лицензия: Freeware
Платформа: Windows
Языки: PHP

Если тебе нужно провести статический анализ PHP-приложения, рекомендую
попробовать PHP Bug Scanner , которую написал наш автор - raz0r. Работа
проги основана на сканировании различных функций и переменных в PHP-скриптах,
которые могут быть задействованы при проведении веб-атак. Описание таких
ситуаций оформляется в виде так называемых пресетов, причем в программу уже
включены 7 специальных прессетов, сгруппированных по категориям:

code execution;
command execution;
directory traversal;
globals overwrite;
include;
SQL-injection;
miscellaneous.

Забавно, что прога написана на
PHP/WinBinder и скомпилирована
bamcompile , поэтому выглядит так же, как и обычное Windows-приложение. Через
удобный интерфейс пентестер может включить или отключь анализ кода на наличие
тех или иных уязвимостей.

Pixy

Сайт:
pixybox.seclab.tuwien.ac.at
Лицензия: Freeware
Платформа: Unix, Windows
Языки: PHP

В основе работы инструмента - сканирование исходного кода и построение графов
потоков данных. По такому графу прослеживается путь данных, которые поступают
извне программы - от пользователя, из базы данных, от какого-нибудь внешнего
плагина и т.п. Таким образом строится список уязвимых точек (или входов) в
приложениях. С помощью паттернов, описывающих уязвимость, Pixy проверяет такие
точки и позволяет определить XSS- и SQL-уязвимости. Причем сами графы, которые
строятся во время анализа, можно посмотреть в папке graphs (например,
xss_file.php_1_dep.dot) - это очень полезно для того чтобы понять, почему именно
тот или иной участок кода считается Pixy-уязвимым. Вообще, сама разработка
крайне познавательна и демонстрирует, как работают продвинутые утилиты для
статического анализа кода. На страничке

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

Ounce 6

Сайт: www.ouncelabs.com/products
Лицензия: Shareware
Платформа: Windows

Увы, существующие бесплатные решения пока на голову ниже, чем коммерческие
аналоги. Достаточно изучить качество и детальность отчета, который составляет
Ounce 6 – и понять, почему. В основе программы лежит специальный
анализирующий движок Ounce Core, который проверяет код на соответствие правилам
и политикам, составленными командой профессиональных пентестеров,
аккумулировавших опыт известных security-компаний, хакерского комьюнити, а также
стандартов безопасности. Программа определяет самые разные уязвимости в коде: от
переполнения буфера до SQL-инъекций. При желании Ounce несложно интегрируется с
популярными IDE, чтобы реализовать автоматическую проверку кода во время сборки
каждого нового билда разрабатываемого приложения. Кстати говоря,
компанию-разработчика - Ounce Labs - летом этого года приобрела сама IBM. Так
что продукт, скорее всего, продолжит развитие уже как часть одного из
коммерческих приложений IBM.

Klocwork Insight

Сайт: www.klocwork.com
Лицензия: Shareware
Платформа: Windows
Языки: C++, Java, C#

Долгое время этот, опять же, коммерческий продукт реализовал статическое
сканирование кода только для C, C+ и Java. Но, как только вышли Visual Studio
2008 и.NET Framework 3.5, разработчики заявили о поддержке C#. Я прогнал
программу на двух своих вспомогательных проектах, которые на скорую руку написал
на "шарпе" и программа выявила 7 критических уязвимостей. Хорошо, что они
написаны исключительно для внутреннего использования:). Klocwork Insight
изначально настроен, прежде всего, на работу в связке с интегрированными средами
разработки. Интеграция с теми же Visual Studio или Eclipse выполнена чрезвычайно
удачно – начинаешь всерьез задумываться, что такая функциональность должна быть
реализована в них по умолчанию:). Если не брать в расчет проблемы с логикой
работы приложения и проблемы с быстродействием, то Klocwork Insight
отлично справляется с поиском переполнения буфера, отсутствия фильтрации
пользовательского кода, возможности SQL/Path/Cross-site инъекций, слабого
шифрования и т.п. Еще одна интересная опция – построение дерева выполнения
приложения, позволяющего быстро вникнуть в общий принцип работы приложения и
отдельно проследить, например, за обработкой какого-либо пользовательского
ввода. А для быстрого конструирования правил для проверки кода предлагается даже
специальный инструмент - Klocwork Checker Studio .

Coverity Prevent Static Analysis

Сайт: www.coverity.com/products
Лицензия: Shareware
Платформа: Windows
Языки: C++, Java, C#

Один из самых известных статических анализаторов кода на C/C++, Java и C#.
Если верить его создателям, – решение используется более чем 100.000
разработчиков по всему миру. Продуманные механизмы позволяют автоматизировать
поиск утечек памяти, неотловленных исключений, проблем с быстродействием и,
конечно же, уязвимостей в безопасности. Продукт поддерживает разные платформы,
компиляторы (gcc, Microsoft Visual C++ и многие другие), а также интегрируется с
различными средами разработки, прежде всего Eclipse и Visual Studio. В основе
обхода кода используются не тупые алгоритмы обхода от начала до конца, а что-то
вроде отладчика, анализирующего, как программа поведет в себя в различных
ситуациях после встречи ветвления. Таким образом достигается 100% покрытия кода.
Столь сложный подход потребовался в том числе, чтобы всецело анализировать
многопоточные приложения, специально оптимизированные для работы на многоядерных
процессорах. Coverity Integrity Center позволяет находить такие ошибки
как состояние гонки (ошибка проектирования многозадачной системы, при которой
работа системы зависит от того, в каком порядке выполняются части кода), тупики
и многое другое. Зачем это нужно реверсерам? Спроси об этом разработчиков 0day
сплоитов для Firefox и IE:).

OWASP Code Crawler

Сайт: www.owasp.org
Лицензия: GNU GPL
Платформа: Windows
Языки: Java, C#, VB

Создатель этой тулзы Алессио Марциали - автор двух книжек по ASP.NET,
авторитетный кодер высоконагруженных приложений для финансового сектора, а также
пентестер. В 2007 году он опубликовал информацию о критических уязвимостях в 27
правительственных сайтах Италии. Его детище – OWASP Code Crawler –
предназначенное для статического анализа кода.NET и J2EE/JAVA, открыто доступно
в инете, а в конце года автор обещается выпустить новую версию программы с
намного большей функциональностью. Но самое-то главное реализовано уже сейчас –
анализ исходников на C#, Visual Basic и Java. Файлы для проверки выбираются
через GUI-интерфейс, а сканирование запускается автоматически. Для каждого
проблемного участка кода выводится описание уязвимости в разделе Threat
Description. Правда, поле OWASP Guidelines , вероятно, указывающее пути
решения проблемы, увы, пока не доступно. Зато можно воспользоваться
экспериментальной особенностью сканирования кода на удаленной машине, доступной
во вкладке Remote Scan. Автор обещает серьезно прокачать эту возможность и, в
том числе, агрегировать исходники приложения для анализа прямо из системы
контроля версий.

WARNING

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

В связи с растущим объемом разрабатываемого ПО проблема безопасности становится все более актуальной. Одним из вариантов ее решения может стать применение безопасного цикла создания продуктов, включая планирование, проектирование, разработку, тестирование. Такой подход позволяет получать на выходе решение с продуманной системой безопасности, которое не потребуется затем многократно “латать" из-за существующих уязвимостей. В данной статье пойдет речь об одной из важных практик, применяемых на этапе тестирования, – статическом анализе кода.

Александр Миноженко
Старший исследователь департамента анализа кода
в ERPScan (дочерняя компания Digital Security)

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

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

Недостатков у такого метода немало. Основным является то, что множество "подозрительных" конструкций в коде не всегда являются дефектами. В большинстве случаев такой код может быть синтаксически правильным и работать корректно. Соотношение "шума" к реальным дефектам может достигать 100:1 на больших проектах. Таким образом, разработчику приходится тратить много времени на его отсеивание от реальных дефектов, что отменяет плюсы автоматизированного поиска.

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

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

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

Основным достоинством этого типа анализаторов является меньше количество "шума" за счет частичного моделирования выполнения программ и возможность обнаружения более сложных дефектов.

Процесс поиска уязвимостей в действии

Для иллюстрации приведем процесс поиска уязвимостей инъекции кода и SQL-инъекции (рис. 1).

Для их обнаружения находятся места в программе, откуда поступают недоверенные данные (рис. 2), например, запрос протокола HTTP.

На листинге (рис. 1) 1 на строке 5 данные получаются из HTTP запроса, который поступает от пользователей при запросе Web-страницы. Например, при запросе страницы “http://example.com/main?name =‘ or 1=‘1”. Строка or 1=‘1 попадает в переменную data из объекта request, который содержит HTTP-запрос.

Дальше на строке 10 идет вызов функции Process с аргументом data, которая обрабатывает полученную строку. На строке 12 – конкатенация полученной строки data и запроса к базе данных, уже на строке 15 происходит вызов функции запроса к базе данных c результирующим запросом. В результате данных манипуляции получается запрос к базе данных вида: select * from users where name=‘’ or ‘1’=‘1’.

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

Статические анализаторы работают похожим образом: помечают данные, которые поступают из недоверенного источника, отслеживаются все манипуляции с данными и пытаются определить, попадают ли данные в критичные функции. Под критичными функциями обычно подразумеваются функции, которые исполняют код, делают запросы к БД, обрабатывают XML-документы, осуществляют доступ к файлам и др., в которых изменение параметра функции может нанести ущерб конфиденциальности, целостности и доступности.

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

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

Автоматизированный поиск уязвимостей

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

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

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

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

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

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

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

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

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

Колонка эксперта

Кибервойны: кибероружие

Петр
Ляпин

Начальник службы информационной безопасности, ООО “НИИ ТНН” (“Транснефть”)

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

Во-первых, война – международное явление, в котором участвуют два или более государства. Война подчиняется своим законам. Один из них гласит: "воюющие не пользуются неограниченным правом в выборе средств нанесения вреда неприятелю" 1 .

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

В-третьих, понятие кибервойны и кибероружия ни в одном действующем международном акте нет. Тем не менее следует разграничивать киберсредства, предназначенные для нанесения вреда (собственно кибероружие), и средства различного рода шпионажа. При этом термин "кибероружие" широко используется в том числе видными представителями научного сообщества.

Удачным видится определение кибероружия, данное профессором МГЮА В.А. Батырем: технические и программные средства поражения (устройства, программные коды), созданные государственными структурами, которые конструктивно предназначены для воздействия на программируемые системы, эксплуатацию уязвимостей в системах передачи и обработки информации или программно-технических системах с целью уничтожения людей, нейтрализации технических средств, либо разрушения объектов инфраструктуры противника 2 . Это определение во многом соответствует объективной действительности – не всякий "удачный вирус" есть кибероружие.

Так, к кибероружию можно отнести: Stuxnet и Flame, ботнеты, используемые для распределенных атак, массово внедряемые на этапе производства элементной базы аппаратные и программные закладки. Последнее, к слову, серьезнейшая проблема, масштаб которой невозможно переоценить. Достаточно взглянуть на перечень закладок АНБ США (от коммутаторов до USB-кабелей), опубликованный немецким СМИ Spiegel в декабре 2013 г. Смартфоны, ТВ, холодильники и прочая бытовая техника, подключенная к Интернету, вообще стирает всякие границы прогнозов.

___________________________________________
1 Дополнительный протокол I 1977 г. к Женевским конвенциям о защите жертв войны 1949 г.
2 Статья В.А. Батыря в Евразийском юридическом журнале (2014, №2) “Новые вызовы XXI в. в сфере развития средств вооруженной борьбы".

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

Обзор кода (code review) – один из самых старых и надежных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе чтения кода выявляются ошибки или участки кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Задачи, решаемые программами статического анализа кода можно разделить на 3 категории:

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

Другие преимущества статического анализа кода:

Полное покрытие кода. Статические анализаторы проверяют даже те фрагменты кода, которые получают управление крайне редко. Такие участки кода, как правило, не удается протестировать другими методами. Это позволяет находить дефекты в обработчиках редких ситуаций, в обработчиках ошибок или в системе логирования.
Статический анализ не зависит от используемого компилятора и среды, в которой будет выполняться скомпилированная программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки . Такие ошибки могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода. Другой интересный пример скрытых ошибок приводится в статье " ".
Можно легко и быстро обнаруживать опечатки и . Как правило, нахождение этих ошибок другими способами является кране неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида "strcmp(A, A)". Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Недостатки статического анализа кода

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

Ошибки, обнаруживаемые статическими анализаторами весьма разнообразны. Вот, например, которые реализованы в инструменте PVS-Studio. Некоторые анализаторы специализируются на определенной области или типах дефектов. Другие, поддерживают определенные стандарты кодирование, например MISRA-C:1998, MISRA-C:2004, Sutter-Alexandrescu Rules, Meyers-Klaus Rules и так далее.