AppChecker — инструмент статического анализа

В настоящее время информационные технологии проникли практически во все сферы ведения бизнеса. Для решения бизнес-задач создаются крупные, распределенные, постоянно модифицируемые информационные системы с тенденцией к усложнению. Они могут иметь в своем составе как готовые решения, так и внешние IT-сервисы (SaaS), собственные и заказные разработки, бесплатные продукты с открытым исходным кодом (open source). Проблемы в их работе приводят к нарушению информационной безопасности, а как следствие, к финансовым и репутационным потерям бизнеса. По данным исследования [9], последние четыре года финансовые потери бизнеса растут из-за кибератак. Повышение сложности используемых программных комплексов, их включение в контур систем управления государством и производством промышленной продукции требуют постоянного совершенствования методов тестирования, испытаний и контроля программного обеспечения.

Большинство методов анализа ПО, применяемого в аудите безопасности программных систем, можно разделить на две группы (рис. 1) — динамические методы (функциональное тестирование) и статические методы (структурное тестирование).

Рис. 1. Примерная классификация видов анализа программ (цветом выделены те виды анализа, о которых говорится в данной статье)

Динамический анализ представляет собой совокупность всех методов анализа программного обеспечения, реализуемых с помощью программ на реальном или виртуальном процессоре. Такие способы наиболее востребованы при исследовании программ методом «черного ящика» (black box), когда имеется доступ лишь к внешним интерфейсам программного обеспечения без учета их структуры, внутренних интерфейсов и состояния [5]. Этот подход не всегда эффективен при поиске ошибок, связанных с комбинациями редко используемых входных данных, а также при выявлении скрытого программного функционала (программных закладок), внесенного туда преднамеренно.

Для своей работы статический анализ не требует реализации программного кода и допускает полную или частичную автоматизацию процесса, но предполагает доступ не только к загрузочным и объектным модулям, но и к исходным текстам программной системы, к информации, связанной со средой компиляции и выполнением программных компонентов [3–5].

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

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

Статический анализ исходных текстов программного обеспечения тесно связан с принципами работы компиляторов. Многие подходы такого анализа основаны на некоторых элементах компиляции, в частности, промежуточное представление исходных текстов в статических анализаторах эволюционирует совместно с развитием теории компиляторов. Современные методы анализа в целях унификации алгоритмов используют различные модели представления кода, например лексический разбор, синтаксическое дерево, дерево Канторовича, графы потока данных и управления и т. д. [1].

Подход, получивший название сигнатурного анализа, подразумевает поиск дефектов в программном коде путем сопоставления фрагментов кода с образцами из базы данных шаблонов (сигнатур) дефектов безопасности. В зависимости от технологии, применяемой при сопоставлении фрагмента кода и шаблона, а также от промежуточного представления, могут использоваться как обычные алгоритмы поиска подстроки в строке, так и регулярные выражения, специальные языки запросов по структурированной информации, в частности XQuery для XML, или специально разработанные для этой задачи способы сопоставления. В [2] приведены примеры правил формирования сигнатур ошибок, соответствующих стандарту CWE. Признакам потенциально опасных конструкций в программных системах и методам оценки их безопасности посвящены статьи 6, 7].

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

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

Рис. 2. Структура статического анализатора

На начальном этапе решение задачи анализа исходного кода напоминает действия компилятора либо интерпретатора (в случае динамического языка). Исходные тексты разбиваются на лексемы, на основании которых впоследствии строится абстрактное синтаксическое дерево (Abstract syntax tree — AST) и в дальнейшем семантический граф (Abstract semantic graph — ASG). Далее AST и ASG анализируются механизмом, подобным поиску регулярных выражений в тексте, либо используются скрипты для анализа. Помимо этого, анализ графов выполнения и потоков данных (Data Flow analysis) может дать полезную информацию.

Примеры дефектов кода

Самые распространенные виды дефектов кода — ошибки программирования и злонамеренно внесенный код. Следует заметить, что не всякая ошибка программирования приводит к возникновению уязвимости, а только те, в результате эксплуатации которых страдают защищенность, целостность и доступность данных. Злонамеренно внесенный код, как правило, позволяет получить несанкционированный доступ к системе, но бывают и другие типы дефектов, приводящие, например, к удаленному выполнению кода, сбору и отправке конфиденциальной информации либо к реализации несанкционированных действий при наступлении определенного момента времени (time bomb).

К наиболее известным и опасным уязвимостям нужно отнести уязвимости следующих видов:

отсутствие проверки вводимых данных — может привести к реализации SQL-инъекций, инъекций кода, межсайтового скриптинга, обхода каталогов;
ошибки работы с памятью — переполнение буфера, необнуленные указатели;
ошибки реализации системы безопасности — позволяют эксплуатировать давно известные «закрытые» уязвимости.

Отсутствие проверки вводимых данных

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

Если в поле ввода, из которого берется параметр $name, ввести «vasia’; drop table ‘users», то таблица users будет удалена, что приведет к потере работоспособности системы. Для предотвращения такого сценария выполнения необходимо использовать безопасный для SQL-инъекции код:

$stmt = prepare_query(«SELECT * FROM users WHERE username =?»);

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

Ошибки работы с памятью

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

int main(int argc, char *argv[])

📎📎📎📎📎📎📎📎📎📎