Уязвимости в программном обеспечении были, есть и будут одними из основных ворот, через которые злоумышленники реализуют свои атаки. Поэтому уже не первый год в тренде так называемая безопасная разработка – все больше вендоров уделяют внимание выявлению и устранению уязвимостей на этапе создания программных продуктов. Один из главных инструментов для этого – анализ кода на наличие уязвимостей и закладок. Даниил Чернов, директор Центра Solar appScreener компании «Ростелеком-Солар», рассказал о том, какие технологии анализа кода сейчас наиболее востребованы, в каком направлении они развиваются, какие изменения могут произойти в этой области в ближайшем и далеком будущем.
Динамический, статический и бинарный анализ
Сегодня есть две наиболее зрелые и востребованные технологии анализа кода – динамический анализ (DAST – Dynamic Application Security Testing) и статический анализ (SAST – Static Application Security Testing). Разновидностью SAST является бинарный анализ.
Код ошибки: 0xc000000f как исправить? WINDOWSsystem32winload.exe | Восстановление Windows 10/8/7
Динамический анализ – его также называют методом «Черного ящика» – представляет собой проверку программы на наличие уязвимостей непосредственно во время ее выполнения. У этого подхода есть свои преимущества.
Во-первых, поскольку уязвимости находятся в исполняемой программе и обнаружение ошибки происходит с помощью ее эксплуатации, возникает меньше ложных срабатываний, чем при использовании статического анализа. Плюс для выполнения данного вида анализа не нужен исходный код.
Но есть и слабые места, в частности, данным методом нельзя обнаружить все возможные уязвимости, в связи с чем существуют риски пропущенных уязвимостей. Не все уязвимости могут себя проявить при таком методе тестирования. Например, временная бомба или захардкоженные креды. Кроме того, метод требует максимально точного воспроизведения боевой среды при тестировании.
Статический анализ – метод «Белого ящика» – представляет собой тип тестирования, при котором, в отличие от динамического анализа, не происходит выполнения программы, а анализируется весь ее код. В результате мы имеем нахождение большего количества уязвимостей. Также метод выгодно отличает возможность внедрения в начальные стадии разработки: чем раньше обнаруживаем уязвимость, тем дешевле обходится ее устранение.
Ищем ошибки в коде JavaScript. Дебаг для начинающих
У метода есть два недостатка. Первый – наличие ложноположительных срабатываний. Как следствие – необходимость оценки, что перед тобой реальная уязвимость или ошибка сканера. Второй недостаток – необходимость наличия исходного кода программы, который не всегда доступен.
В последнем случае помогает бинарный анализ – он позволяет с помощью технологий реверс-инжиниринга провести статический анализ кода, даже если у нас нет исходника. Когда в 2015 году мы выводили на рынок анализатор кода приложений Solar appScreener, эта функциональность уже была заложена в системе. Мы видели тогда и видим сейчас, что в реальной жизни это зачастую единственная возможность грамотно и полноценно выявить уязвимости в приложениях.
Например, нам нужно убедиться в том, что исходный код, который мы проверяли, – тот самый, который потом пойдет в продакшн. Помимо ситуаций, когда кто-либо намеренно вносит в код закладки, ряд уязвимостей может добавить и компилятор. И это отнюдь не экзотическая ситуация: компилятор тоже пишут люди, и он не застрахован от ошибок. В общем, нам нужно взять из продакшна исполняемый файл и проверить его на уязвимости.
Альтернативный вариант – прогнать приложение через динамический анализатор: перед нами черный ящик, мы не можем его открыть, но можем на него воздействовать – «пнуть, поднять, потрясти, уронить». И по результатам этого воздействия сделать выводы. При динамическом анализе на вход приложения подаются разные данные, в текстовые поля вводятся различные последовательности, в случае с веб-сайтом посылаются разнообразные команды, протоколы, пакеты. И по ответу от приложения мы делаем вывод, есть ли в нем уязвимости. DAST действительно хорош для веб-приложений, потому что можно повоздействовать на систему, защищенную при этом файрволом.
Однако DAST помогает обнаружить только определенный спектр уязвимостей. А, например, угрозы вроде временной бомбы, которая по триггеру времени запустит в систему вредонос, скрытую «учетку», небезопасный пароль и прочее динамическим анализом не обнаружить. Бинарный анализ же делает из черного ящика белый, позволяя в ходе статического анализа увидеть его содержимое.
Кроме того, бывают ситуации, когда исходный код разработанной системы утерян, при этом она активно эксплуатируется и резко отказаться от нее невозможно. Бинарный анализ поможет проверить эту систему на наличие уязвимостей, чтобы принять оперативные меры по защите.
True or False: как решить главную проблему автоматизированного анализа кода?
Ложные срабатывания – проблема любых систем, которые автоматически что-то анализируют и выдают результат. Очевидно, что она актуальна и для анализаторов кода. Чем больше ложных срабатываний, тем дороже использование инструмента для пользователя. Ведь на верификацию тратятся человеческие ресурсы – время.
Сегодня есть несколько путей развития технологий для минимизации ложных срабатываний. Один из самых хайповых – применение искусственного интеллекта, а точнее его подраздела – машинного обучения (МО). Какими способами можно искать уязвимости в коде с помощью МО?
Во-первых, можно попытаться обучить МО-анализатор вручную: написать множество примеров правильного и неправильного кода и научить анализатор искать такие ошибки. Минус подхода в том, что для обучения анализатора нам придется потратить много времени на подготовку подходящих примеров.
Есть еще вариант — пометить код реальных приложений с указанием фрагментов, в отношении которых анализатор должен выдавать предупреждение о наличии ошибки. В любом случае необходимо будет проделать большой объем работы, так как для обучения необходимы десятки тысяч примеров ошибок кода. Если же учесть, что существуют уязвимости (например, утечка памяти), которые могут содержаться в коде, написанном почти бесконечным числом вариаций, то необходимый для обучения объем примеров делает задачу фактически невыполнимой.
Во-вторых, можно не готовить примеры вручную, а обучать МО-анализатор на основе больших объемов открытого исходного кода. Можно отслеживать историю коммитов на GitHub и выявлять закономерности изменения или исправления программного кода. Однако проблема в том, что правки на GitHub вносятся довольно хаотично: например, пользователь не хочет тратить время на внесение каждой правки в отдельности – и он где-то вносит пару изменения, а где-то просто переписывает кусок кода. Тогда даже человек не сможет разобраться, связаны ли эти исправленные ошибки между собой.
Можно, конечно, нанять маленькую армию специалистов, которые будут проверять исходный код и указывать, где исправлена ошибка – а где код переписан, где добавлена новая функция – а где изменились требования. То есть, по сути, мы опять возвращаемся к ручному обучению. Не говоря уже о росте стоимости и длительности решения задачи. Или же можно попытаться автоматически определять ошибки в открытом исходном коде: можно попробовать запрограммировать такой поиск, что будет непросто, а главное, возникнут вопросы к качеству такого анализа.
Таким образом, в целом использование ИИ для анализа кода – очень трудозатратная и недешевая история при неочевидном результате.
Но есть и другой метод борьбы с ложными срабатываниями – математический.
Нечеткая логика: как это работает
Нечеткая логика – относительно новый раздел математики. Он является обобщением классической логики и теории множеств и базируется на понятии нечеткого множества, впервые введенного в 1965 году. Если в обычной логике у нас есть true или false, 0 или 1, то нечеткая логика оперирует градациями между true и false. Она может сказать, что событие верно на столько-то процентов и на столько-то неверно, – и это ближе к мышлению человека.
Представьте, что у вас есть стакан воды и нужно сказать, что вода холодная, если ее температура ниже 15 градусов, и теплая, если выше 15 градусов. Мы опускаем палец в стакан (допустим, там 16 градусов, но мы об этом не знаем). И мы не скажем: «Да, она точно теплая». На пограничных значениях мы будем внутренне колебаться: вроде теплая, но скорее холодная. Нечеткая логика помогает нам уйти от линейного мышления.
В обычном линейном мышлении, когда систему научили принимать решение, что это true или false, при выставлении математического порога (допустим, мы хотим меньше ложных срабатываний) приходится устанавливать для машины жёсткие фильтры принятия решений. Тогда она начнет выдавать меньше ложных срабатываний, но при этом начнет пропускать реальные уязвимости. Двигаем линейный фильтр в обратную сторону – машина перестает пропускать уязвимости, но при этом ложных срабатываний становится очень много.
Поэтому в своей системе мы реализовали механизм борьбы с уязвимостями на основе математического аппарата нечеткой логики – Fuzzy Logic Engine (FLE), который позволяет тонко настраивать линейные фильтры, балансируя между снижением ложных срабатываний и потерей точности выявления уязвимостей. Фильтры в системе позволяют, например, отображать лишь те уязвимости, в которых FLE полностью уверен. Кроме того, можно практически ювелирно настроить уровень уверенности системы в наличии уязвимости. С помощью шкалы Confidence можно, например, задать для уязвимостей критичного уровня более жесткие критерии, по которым система будет относить потенциальные уязвимости к реальным.
Для уязвимостей средней и низкой критичности можно задать более мягкие критерии оценки.
Чем больше языков, тем лучше
Языков программирования становится все больше, многие из новых быстро набирают популярность. Например, язык Rust, который позиционируется как безопасная замена С++ и сегодня часто используется для написания десктопных приложений и бэкэндов. Или Go (Golang), применяемый для создания высоконагруженных сервисов – площадок онлайн-торговли, ДБО, мессенджеры и т.п. Dart, предназначенный для написания веб и мобильных клиентов.
И нередко бывает так, что какая-то часть системы написана на языке, который можно проверить не всеми инструментами. Поэтому, если мы хотим, чтобы анализ кода был эффективным и удобным, важно, чтобы все языки были на борту. Пользователь не должен задаваться вопросом, на каких языках написано приложение, все ли языки поддерживает анализатор. Код должен загружаться в анализатор, который сам определит, какие языки содержатся в приложении, и все их проверит, ничего не пропуская. Именно по такому принципу мы реализуем Solar appScreener: в апреле прошлого года добавили поддержку Dart и продолжаем лидировать по количеству поддерживаемых языков – сейчас их 36.
C#: обработка ошибок
Исключения, их обработка, и некоторые другие моменты, связанные с ошибками в приложении на C#.
Исключения (Exceptions) и инструкция try
Инструкция try отмечает блок кода как объект для обработки ошибок или очистки. После блока try обязательно должен идти либо блок catch , либо блок finally , либо они оба. Блок catch выполняется, когда внутри блока try возникает ошибка. Блок finally выполняется после того, как прекращает выполнять блок try (или, если присутствует, блок catch ), независимо от того, выполнился ли он до конца или был прерван ошибкой, что позволяет выполнить так называемый код очистки.
Блок catch имеет доступ к объекту исключения ( Exception ), который содержит информацию об ошибке. Блок catch позволяет обработать исключительную ситуацию и как-либо скорректировать ошибку или выбросить новое исключение. Повторное выбрасывание исключения в блоке catch обычно применяется с целью логирования ошибок или чтобы выбросить новое, более специфическое исключение.
Блок finally добавляет в программу прогнозируемость, позволяя выполнить определенный код при любых обстоятельствах. Это может быть полезно для выполнения операций очистки, например, закрытия сетевого подключения и т.д.
В целом конструкция try выглядит следующим образом:
. . . // в пределах этого блока может быть выброшено исключение
catch ( ExceptionA ex )
. . . // обработчик исключений типа ExceptionA
catch ( ExceptionB ex )
. . . // обработчик исключений типа ExceptionB
. . . // код очистки
Например, следующий код выбросит ошибку DivideByZeroException (поскольку делить на ноль нельзя) и наша программа завершить досрочно:
int x = 3 , y = 0 ;
Console . WriteLine ( x / y ) ;
Чтобы этого избежать можно использовать конструкцию try :
int x = 3 , y = 0 ;
Console . WriteLine ( x / y ) ;
catch ( DivideByZeroException ex )
Console . Write ( «y cannot be zero. » ) ;
// выполнение программы продолжится отсюда
Обработка исключений довольно ресурсоёмкая операция, поэтому на практике для таких случаев как в примере ее лучше не использовать (лучше непосредственно перед делением проверить делить на равенство нулю).
Когда выбрасывается исключение, CLR проверяет выброшено ли оно непосредственно внутри блока try , который может обработать данное исключение. Если да, выполнение переходит в соответствующий блок catch . Если блок catch успешно завершается, выполнение переходит к следующей после блока try инструкции (если имеется блок finally , то сначала выполняется он). Если же исключение выброшено не внутри блока try или конструкция try не содержит соответствующего блока catch , выполнение переходит в точку вызова метода (при этом сначала выполняется блок finally ), и проверка повторяется снова.
Если не одна функция в стэке вызовов не способна обработать исключение, ошибка выводиться пользователю и программа завершается досрочно.
Оговорка catch
В оговорке catch указывается какой тип исключения она должна перехватывать. Это может быть либо System.Exception , либо его производный класс. Перехватывая непосредственно System.Exception , мы перехватим все возможные ошибки. Это может быть полезно в нескольких случаях:
- программа потенциально должна и может продолжить работать несмотря на ошибки любых типов
- исключение будет выброшено повторно в блоке catch , например, после логирования ошибок
- блок catch является последним в очереди, способным предотвратить аварийное завершение программы
Однако обычно перехватываются исключения более специфического типа, чтобы избежать ситуации, когда обработчику ошибки придется иметь дело с исключением, для которого он не предназначен (например, OutOfMemoryException ).
Можно обработать несколько типов исключений с помощью нескольких оговорок catch:
Источник: devkazakov.com
Лучшие инструменты пентестера: статический анализ кода
У каждого из команды ][ — свои предпочтения по части софта и утилит для
пентеста. Посовещавшись, мы выяснили: выбор так разнится, что можно составить
настоящий джентльменский набор из проверенных программ. На том и решили. Чтобы
не делать сборную солянку, весь список разбит на темы. Сегодня мы разберем
статические анализаторы кода для поиска уязвимостей в приложениях, когда на
руках – их исходники.
Наличие исходных кодов программы существенно упрощает поиск уязвимостей.
Вместо того чтобы вслепую манипулировать различными параметрами, которые
передаются приложению, куда проще посмотреть в сорцах, каким образом она их
обрабатывает. Скажем, если данные от пользователя передаются без проверок и
преобразований, доходят до 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
Сайт:
cppcheck.wiki.sourceforge.net
Лицензия: 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-интерфейсе тут неуместно даже упоминать: все
осуществляется через консоль. Для запуска есть несколько ключей, но в самом
простом случае достаточно указать в качестве параметра путь к исходникам:
Наградой за старание будет цветастый отчет о потенциально эксплуатируемых
местах в коде. Надо сказать, что, помимо самого скрипта (а это всего 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
Если тебе нужно провести статический анализ 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
Информация представлена в целях ознакомления и, прежде всего, показывает,
каким образом разработчики могут избежать критических ошибок во время разработки
приложений. За использование полученных знаний в незаконных целях ни автор, ни
редакция ответственности не несут.
Источник: xakep.ru