Исследование программного кода на предмет ошибок

В настоящее время информационные технологии проникли практически во все сферы ведения бизнеса. Для решения бизнес-задач создаются крупные, распределенные, постоянно модифицируемые информационные системы с тенденцией к усложнению. Они могут иметь в своем составе как готовые решения, так и внешние 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).

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

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

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

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

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

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

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

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

strcpy(buf, argv[1]);
// копирование

// без проверки длины

Пример безопасного кода:

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

strncpy(buf, argv[1], sizeof(buf));

// копируется не больше

Ошибки реализации

При проектировании и разработке решений для безопасности информационной системы не следует допускать появления в програм­мном коде уязвимостей, которые в дальнейшем могут создать прецеденты нарушения информационной безопасности. К таким уязвимостям относятся:

Вредоносный код

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

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

Эффективность статического анализа

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

Использование AppСhecker [8] позволяет существенно упростить и сократить затраты на ревизию кода при разработке программ, а также повысить качество кода и сократить количество ошибок и уязвимостей еще на этапе проектирования, что также позитивно скажется на затратах на доработку и поддержку выпускаемого ПО.

Помимо основного функционала в любом программном обеспечении, взаимодействующем с пользователем, очень важно удобство его применения. Удобный и понятный интерфейс (рис. 3), интеграция в процесс разработки, простота установки, обновления и поддержки становятся важными характеристиками анализаторов кода. Тем не менее сделать анализатор полностью автоматическим, действующим по «нажатию одной кнопки», невозможно.

Рис. 3. Общий вид рабочего экрана AppChecker

Как уже упоминалось, работа анализатора во многом близка работе компилятора. И для того чтобы провести качественный анализ, требуются те же действия, которые выполняет система сборки: проанализировать зависимости в проекте, распознать и «подключить» библиотечные функции и т. д., что может потребовать дополнительных настроек процесса анализа. В сравнении с другими статическими анализаторами, AppСhecker предоставляет пользователям бо? льшую гибкость в настройке: он понятен простым пользователям, а опытные разработчики смогут интегрировать его в процесс сборки любой сложности.

Важной составляющей безопасности кода является применение проверенных сторонних компонентов — библиотек или готовых программ с открытым исходным кодом. Их можно проверить, сообщая авторам о найденных уязвимостях и создавая базу уязвимостей open-source библиотек. Это особенно актуально для поддерживаемых анализатором AppСhecker интерпретируемых языков PHP, Javascript, в которых программы хранятся в виде исходных текстов.

Заключение

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

Анализ безопасности исходного кода как ключевой элемент DevSecOps

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

Введение

Мы продолжаем обсуждать различные аспекты методологии DevSecOps в рамках цикла онлайн-конференций AM Live. В феврале ведущие эксперты рынка рассказали зрителям об основах безопасной разработки, а очередная встреча, прошедшая в конце марта, была посвящена обеспечению безопасности исходного кода. Мы собрали группу экспертов, чтобы обсудить, какие сканеры безопасности исходного кода представлены на рынке, чем отличаются решения классов SAST, DAST и IAST и что такое RASP-инструменты, а также порассуждать о перспективах отрасли.

В студии Anti-Malware. ru собрались:

Модерировал беседу Андрей Бешков — руководитель направления развития бизнеса компании Softline.

Зачем проверять код на безопасность

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

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

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

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

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

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

Использовать ли сканеры с открытым исходным кодом

Ещё один вопрос, который обсудили спикеры онлайн-конференции AM Live, — насколько допустимо использовать бесплатные (open-source) продукты для анализа кода. Как отметили эксперты, такие разработки могут обеспечить некоторый базовый уровень безопасности, однако для поиска уязвимостей второго порядка чаще всего необходимы специализированные ИБ-продукты. Платные инструменты часто обладают расширенной рекомендательной функциональностью. Это важно, поскольку в ряде случаев мало сообщить о проблеме, надо ещё и объяснить, что необходимо сделать, вплоть до автоматического исправления проблемного кода. Детальное описание уязвимостей и разработка рекомендаций по их исправлению требуют очень больших усилий и затрат от разработчиков сканеров, а опенсорс-команды часто ими не обладают.

Как отметил Артём Синицын, не бывает полностью бесплатного ПО и тем более не бывает дешёвой безопасности. В то же время нельзя говорить, что лучше — коммерческий сканер или бесплатный; можно говорить о том, какой инструмент лучше подходит для решения определённой задачи. Можно комбинировать различные ядра для анализа кода на разных стадиях проекта, а также применять разные сканеры для разных разработок.

Мы поинтересовались у зрителей прямого эфира, анализируют ли они исходный код своих проектов на предмет безопасности. Как оказалось, в организациях 30 % респондентов действует специальный регламент по проверке кода. Ещё 20 % опрошенных сообщили, что код анализируется, но этот процесс не поставлен на регулярную основу. Не анализируют код 17 % наших зрителей, а 18 % из них уверены в чистоте используемого в их проектах кода. Отдали процесс обеспечения безопасности кода на аутсорсинг 15 % опрошенных.

Рисунок 1. Анализируете ли вы исходный код своих проектов на безопасность?

Что такое SAST, DAST, IAST и с чего нужно начинать внедрение анализа безопасности исходного кода

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

Анна Архипова:

— Каждый инструмент используется на своём этапе DevSecOps. Статический анализатор поможет при написании кода и определении архитектуры приложения, динамическая проверка и, возможно, IAST будут полезны при сборке и тестировании программы. Ни один из инструментов не обеспечивает полной безопасности кода, но в комплексе они дают хороший результат.

Валерий Куваев:

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

Сергей Деев:

— Компании по-разному подходят к разработке, но если стоит цель сделать этот процесс безопасным, то SAST — это один из базовых инструментов. Однако стоит не противопоставлять статический и динамический анализ, а использовать все доступные инструменты, чтобы сделать код безопасным. Некоторые типы уязвимостей можно определить только в статике, некоторые — только в динамике, а целый ряд проблем находится на стыке возможностей этих двух инструментов.

Дарья Орешкина:

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

Артем Синицын:

— Чтобы понять текущую классификацию решений для сканирования кода, достаточно запомнить пять аббревиатур. Исторически существуют статический (SAST) и динамический (DAST) анализ, а также гибридный подход (IAST). Кроме того, существует FAST, или фаззинг — подраздел динамического тестирования на основе обратной связи. Наконец, нельзя забывать и о RASP (Runtime Application Self-Protection), технологии, которая скорее является внутренним файрволом приложения и используется для анализа и блокировки атак в реальном времени.

Алексей Жуков:

— В контексте безопасности приложений необходимо помнить об ещё одной технологии: WAF (Web Application Firewall). Это — накладное средство безопасности, которое позволяет заблокировать определённые известные уязвимости и выпустить программу дав разработчику время для исправления проблемы.

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

Зрители онлайн-конференции AM Live считают, что в первую очередь необходимо уделять внимание статическому анализу кода. За это в ходе проведённого нами опроса высказались 69 % респондентов. Ещё 21 % опрошенных отдают предпочтение динамическому анализу. За анализ сторонних компонентов и интерактивный анализ (IAST) отдали свои голоса 7 % и 3 % соответственно.

Рисунок 2. На какие способы анализа безопасности приложений вы обращаете внимание в первую очередь?

Что мешает внедрять средства анализа безопасности кода

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

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

На вопрос «Что ограничивает вас во внедрении анализа безопасности исходного кода?» 28 % зрителей онлайн-трансляции ответили, что им мешает сопротивление внутри компании. Столько же голосов набрал вариант «Дефицит внутренних ресурсов». Высокая стоимость технологий анализа исходного кода на безопасность ограничивает 20 % опрошенных, а увеличение срока выхода релизов — 8 % респондентов. Наконец, 16 % наших зрителей сообщили, что в их компании этот процесс находится на стороне подрядчика.

Рисунок 3. Что ограничивает вас во внедрении анализа безопасности исходного кода?

Перспективы рынка: уйдёт ли анализ кода на безопасность в облако

В завершение беседы ведущий конференции AM Live предложил гостям в студии порассуждать о перспективах рынка и, в частности, обсудить то, будут ли анализаторы кода мигрировать в облако. Эксперты отметили, что на западном рынке этот процесс уже идёт и вендоры получают до 50 % своей прибыли от облачных систем безопасности кода. В России этот тренд также заметен, хотя и не так значим. Некоторое недоверие к облачным технологиям в нашей стране обусловлено в том числе и слабой нормативной базой, которая, впрочем, сейчас активно развивается.

Мы спросили у зрителей конференции, готовы ли они отдать анализ исходного кода в облако. Большинство участников опроса — 62 % — отрицательно отнеслись к такой возможности. Готовы использовать облачные технологии в том случае, если серверы находятся на территории России, 19 % респондентов; столько же доверяют анализу кода в облаке без дополнительных условий.

Рисунок 4. Готовы ли вы производить анализ безопасности исходного кода в облаке?

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

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

По итогам конференции мы поинтересовались у зрителей тем, как изменилось их мнение относительно технологий анализа кода после просмотра прямого эфира. Почти четверть опрошенных — 24 % — заинтересовались анализаторами и выразили готовность начать их тестирование. Чуть больше — 28 % респондентов — считают, что такое решение будет избыточно для их компании. Почти треть участников опроса уже используют сканеры исходного кода — за этот вариант отдали свои голоса 32 % зрителей. Ещё 4 % опрошенных выразили мнение, что спикеры онлайн-конференции не смогли доказать необходимость таких инструментов, а 12 % вообще не поняли, о чём шла речь.

Рисунок 5. Каково ваше мнение относительно анализаторов безопасности исходного кода?

Выводы

Мы планируем продолжить обсуждение различных аспектов DevSecOps с экспертами в этой сфере. Кроме того, зрителей ждут новые выпуски конференции AM Live, посвящённые и другим актуальным для отечественного рынка информационной безопасности вопросам. Чтобы оставаться в курсе ключевых тенденций, иметь возможность в прямом эфире наблюдать дискуссии лидеров мнений и общаться с ними в процессе онлайн-трансляции, подписывайтесь на наш YouTube-канал и включайте уведомления о новых материалах. До встречи на конференции AM Live!