CC BY
47
access control tools was selected. a set of initial data, a given technical task for the development of a complex system. Based on the terms of reference and analysis of software and hardware systems, software was developed that satisfies the tasks set. The results were obtained, carried out by steel work on the justification of the disclosure of the system within the enterprise.
Key words: analysis, system, access control, classification, RFID.
Shaitura Sergey Vladimirovich, candidate of technical sciences, docent, Rector of Burgas, swshay-tura@gmail.com, Russia, Korolev, Technological University named after twice Hero of the Soviet Union, Cosmonaut A.A. Leonov,
Zhidelev Maxim Alexandrovich, master, mzhidelev@yandex.ru, Russia, Korolev, Technological University named after twice Hero of the Soviet Union, Cosmonaut A.A. Leonov,
Gunina Elena Vladimirovna, master, Russia, Korolev, Technological University named after twice Hero of the Soviet Union, pilot-cosmonaut A.A. Leonov
УДК 004.052
DOI: 10.24412/2071-6168-2022-12-408-414
ПРИМЕНЕНИЕ ГИБРИДНОГО АНАЛИЗА ДЛЯ ПОИСКА УЯЗВИМОСТЕЙ В ИСХОДНОМ ПРОГРАММНОМ КОДЕ
Е.М. Баранова, А.Н. Баранов, Н.В. Кулешова, В.А. Пелипенко
В статье рассматриваются статический и динамический методы анализа исходного программного кода, определены достоинства и недостатки методов, предложена модель поиска уязвимо-стей гибридным методом.
Ключевые слова: анализатор кода, статический анализ, динамический анализ, гибридный анализ, ошибки кода, уязвимости.
В настоящее время сложно представить жизнь без программного обеспечения и веб-ресурсов. Уже очень большая часть "рабочей и домашней" деятельности программно автоматизирована: запись на прием к врачу, оплата услуг ЖКХ, отправка писем, заказ еды, перевод денежных средств и многое другое. Однако, не каждый во время использования сайта или программы задумывается над безопасностью своих персональных данных. Казалось бы, у каждой ответственной за ресурс организации имеются политика конфиденциальности и политика обработки персональных данных, и можно совершенно не беспокоиться, ведь у организации все под защитой. Но утечки персональных данных все равно продолжают происходить.
Все базы данных находятся под защитой, а у организации есть строгая политика разграничения доступа сотрудников. И тогда возникает закономерный вопрос: "Откуда утечка данных?". Чаще всего ответом является получение хакерами доступа к внутренним ресурсам организации. Однако практика показывает, что нередко брешь в безопасности возникает вовсе не внутри, а как раз на самом сайте, в самом программном обеспечении. А если быть точнее - в исходном программном коде.
Нередко в исходном коде можно встретить пароли администраторов системы, записанные в разных переменных для проверки и выдаче пользователю роли администратора. Получив доступ к такому написанному коду, злоумышленники также могут воспользоваться базой данных.
Уязвимости безопасности могут также скрываться и в простых вещах. Например, при записи данных в буфер. Если тщательно не проверить написанный алгоритм записи, можно допустить переполнение буфера, что, в свою очередь, также приведет к потере персональных данных.
Подобных ошибок, допущенных при разработке программного обеспечения и приводящих к возникновению уязвимостей безопасности, тысячи, и отследить их довольно сложно. Речь идет не только о сайтах и программах, которыми каждый человек пользуется регулярно, но также и о средствах защиты информации: от уязвимостей в исходном коде не защищены и они.
Анализаторы кода помогают автоматизировать процесс обзора кода. На сегодняшний день существует множество различных анализаторов кода для практически всех языков программирования. Не обошло внедрение данной технологии и область обеспечения информационной безопасности: анализаторы кода активно используются для поиска уязвимостей и недекларированных возможностей.
Возможное нарушение функционирования программных продуктов может повлечь за собой финансовые убытки и снижение репутации. Сбои чаще всего происходят из-за программных ошибок или в результате реализации угроз информационной безопасности. Объясняется это тем, что обзор кода на наличие угроз на этапе разработки занимает достаточно много времени и влечет дополнительные расходы. Поэтому, заказывая сайт или программу, заказчики не задумываются о возможных будущих потерях: реализованных угрозах информационной безопасности.
Если сравнить стоимость ошибки на этапе разработки и непосредственно после, на этапе эксплуатации, то исправление в первом случае будет стоить организации намного дешевле, чем возможное устранение последствий от дефекта. В зависимости от того, когда ошибка появилась и была обнаружена, стоимость её исправления будет сильно меняться. Если принять стоимость устранения дефекта на этапе выработки требований к продукту за одну условную единицу, тогда в табл. 1 представлена средняя стоимость исправления в зависимости от времени внесения и обнаружения.
Таблица1
Средняя стоимость исправления дефектов в зависимости от времени их внесения и обнаружения [1]_
Время обнаружения дефекта
Время внесения дефекта Выработка требований Проектирование архитектуры Конструирование Тестирование системы После выпуска ПО
Выработка требований 1 3 5-10 10 10-100
Проектирование архитектуры - 1 10 15 25-100
Конструирование - - 1 10 10-25
Из таблицы видно, что стоимость исправления ошибки, внесенной на этапе конструирования, будет в 10-25 раз выше на этапе эксплуатации, и сюда еще не входит стоимость устранения последствий. Таким образом, возникает необходимо находить уязвимости на ранних этапах разработки. Анализатор кода в данном случае - первая помощь.
В настоящее время на рынке имеются анализаторы кода, которые анализируют исходный код и выдают отчет о найденных ошибках, уязвимостях и недочетах. При этом анализаторы также могут проверять код на соответствие стандартам, в том числе и стандартам организации.
Существует два вида анализаторов:
динамический анализатор кода: проводит анализ кода программы непосредственно при ее выполнении;
статический анализатор кода: проводит анализ исходного кода программы в целом, не требует запуска разрабатываемой программы.
Внедрение этапа анализа кода в процесс разработки поможет уменьшить количество ошибок и уязвимостей, снизить затраты на их устранение и сделать продукт намного безопаснее.
Статистика показывает, что с ростом проекта растет и плотность ошибок. В табл. 2 представлены данные по ошибкам, найденным статическим анализом.
Таблица 2
Плотность ошибок^ в программном коде_
Размер проекта (число строк кода) Типичная плотность ошибок
Менее 2К 0 - 25 ошибок на 1000 строк кода
2К - 16К 0 - 40 ошибок на 1000 строк кода
16К - 64К 1 - 50 ошибок на 1000 строк кода
64К -512К 2 - 70 ошибок на 1000 строк кода
512К и более 4 -100 ошибок на 1000 строк кода
Есть стандарт, регламентирующий процесс разработки безопасного программного обеспечения - ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Данный стандарт предусматривает использование динамических и статических анализов кода. В соответствии с ГОСТом разработчик должен проводить статический анализ исходного кода программы с целью выявления недостатков и потенциально уязвимых конструкций в ее исходном коде. Статический анализ также следует проводить в отношении компонентов, заимствованных у сторонних разработчиков ПО, если для этих компонентов доступен исходный код. По результатам статического анализа исходного кода программы необходимо проводить доработку программы.
В ГОСТе также прописана необходимость использования динамического анализа кода с учетом особенности архитектуры программы, модели угроз и результатов прошедшего статического анализа [2].
Оба анализатора имеют одинаковый общий алгоритм работы, представленный на рис. 1.
Во время проведения анализа исходных кодов и работы программы используются различные базы, содержащие описания ошибок и уязвимостей программ.
Так существует ряд государственных баз уязвимостей, поддержкой и составлением которых занимаются регуляторы разных стран. Для обеспечения информационной безопасности анализаторы реализуют поддержку данных баз. В России же отечественные решения интегрируются с БДУ ФСТЭК России.
Естественно, у анализаторов имеются собственные базы, по которым они ищут ошибки и уязвимости. Поддержкой таких баз занимаются, как правило, отделы аналитики и исследований. На качество анализа сильно влияет качество данной базы и проводимых по ней диагностик. Еще одним важных критерием является обновление такой базы. Она должна регулярно дополняться информацией о новых уязвимостях информационной безопасности, а также информацией об изменениях в языках программирования и методах разработки программного обеспечения [8].
Анализатор кода - это программа, которой не надо делать перерывы на обед, у которой не притупляется внимание, и которая может проверить весь код за раз. Затраты по времени во много раз меньше, а на рынке представлено множество решений различной ценовой политики.
У статического анализа есть несколько важных достоинств:
1. гарантия полного покрытия исходного кода программы. Так как статическим анализаторам не требуются исходные данные для проверки, а только код, то они проверяют также и те фрагменты кода, которые выполняются крайне редко или вообще не используются в процессе работы программы, что позволяет находить еще больше важных дефектов, ведь такие участки кода, как правило, не удается протестировать другими методами [3].
2. независимость от используемого компилятора и среды, в которой будет выполняться программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки неопределенного поведения. Такие ошибки могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода.
3. возможность легко и быстро обнаруживать опечатки и последствия использования копирования кода. Как правило, нахождение этих ошибок другими методами является кране неэффективной тратой времени и усилий. Тот же обзор кода в силу человеческого фактора вряд ли найдет все опечатки и повторы [3].
Динамический тоже имеет ряд достоинств:
1. независимость от вида выражений в программе. Любое выражение вычисляется, и идет работа с его значением. Это невозможно при статическом анализе.
2. обращение к конкретным ячейкам памяти, в следствие чего не составляет труда проверить программу, в которой часто используются указатели. Рассматриваемый метод анализа всегда дает полную картину зависимостей для данного конкретного запуска программы с данным конкретным набором входных данных, а также никогда не укажет на зависимость операторов там, где ее на самом деле нет [4].
3. исключение появления ложных срабатываний, так как обнаружение ошибки происходит в момент ее возникновения в программе. Следовательно, обнаруженный дефект является не потенциальной ошибкой или уязвимостью, сделанной на основе анализа модели программы, это действительно недочет программы, который необходимо исправить.
4. возможность проверки программ с закрытым исходным кодом и используемых библиотек
[5].
Применение динамического анализа больше всего необходимо там, где главным критерием является надежность программы, время отклика или потребляемые ресурсы.
Оба этих вида анализа позволяют убедиться в корректности работы программы или показать, что она содержит ошибки. Естественно, что для лучшего результата следует пользоваться и другими методами тестирования. Если в ходе всех диагностик не было выявлено дефектов, то это не значит, что программа совсем их не имеет. Даже при полном покрытии кода всевозможными тестами и анализами невозможно дать 100% гарантии, что будут выявлены все ошибки. Все зависит от возможностей выбран-
ных методов и корректности работы проверяющих программ. Так, например, динамический анализ не может искать логические ошибки, а статический все еще выдает много ложных срабатываний, а значит и у этих методов анализа есть недостатки.
Главным недостатком статического анализа является количество ложных срабатываний, ведь такие программы предупреждают обо всех подозрительных местах. А это значит, что проверяемый подозрительный код может быть совершенно корректен. Это нельзя назвать чисто ложным срабатыванием, скорее ложно-позитивным. В данном случае, только программист может понять, указывает ли анализатор на ошибку или все в анализируемом фрагменте правильно. Ложных срабатываний может быть очень много, и необходимость их просматривать будет занимать значительную часть рабочего времени и ослаблять внимание к участкам кода, где содержатся ошибки и которые необходимо дорабатывать [5]. Это может свести на нет достоинство по времени.
Можно выявить еще один недостаток. Статический анализ, как правило, слаб в диагностике утечек памяти и параллельных ошибок. Чтобы найти подобные ошибки, необходимо выполнить часть программы. Это крайне сложно реализовать. Также подобные алгоритмы требуют очень много памяти и процессорного времени. Как правило, статические анализаторы ограничиваются диагностикой простых случаев. Более эффективным способом выявления утечек памяти и параллельных ошибок является использование инструментов динамического анализа [5].
Однако и динамические анализаторы имеют ряд недостатков. Так как во время динамического анализа всегда вычисляются значения выражений, то при исследовании зависимости в некотором небольшом фрагменте кода программы, необходимо выполнить все предшествующие операторы, чтобы проследить изменения результатов выражений и движение потока этих данных. Если фрагмент находится в конце кода программы, то это существенно повлияет на время выполнения анализа [4].
При динамическом анализе для каждой ячейки памяти необходимо хранить некоторые данные, следовательно, это вынуждает увеличивать размеры ячеек, что снижает точность анализа, либо же существенно уменьшать размеры исходных данных и параметров задачи, что может некорректно отражать реальное поведение программы.
Этот метод дает картину зависимостей только для выбранного набора входных данных. При выполнении и анализе программы на другом наборе данных зависимости могут меняться. В результате, например, анализатор укажет на независимость операторов, тогда как на самом деле они являются зависимыми. Это может привести к генерации некорректной параллельной программы, что является самой значительной проблемой при использовании динамического анализа.
Данная проблема приводит к необходимости составления системы различных тестов, которые бы хорошо отражали поведение программы во всевозможных ситуациях. После проведения анализа на такой системе тестов необходимо объединить полученные зависимости и полученный результат использовать для последующей доработки программы [4].
Таким образом, оба метода анализа имеют свои достоинства и недостатки, и в настоящее время нет утилиты, которая бы окончательно заменила человека в процессе обзора кода, поэтому периодически проводить классический обзор кода все еще необходимо.
Как уже было отмечено, и динамический, и статический анализ выполняют разные функции. Но цель их одна - поиск ошибок и уязвимостей в программе. Однако статический анализ рассматривает исключительно исходный код, а для динамического требуется выполнение программы.
Сравнивать эти два метода нет никакого смысла, можно сразу прийти к выводу: лишь использование и статического, и динамического анализа вместе поможет раскрыть все достоинства обоих методов, уменьшить их недостатки. Гибридный анализ, совмещающий оба этих решения, поможет найти как можно больше уязвимостей в коде и сделать программу намного безопаснее.
Итак, использование обоих методов будет идеальным решением в процессе разработки. Как правило, в проектах среднего и большого размеров используются ночные компоновки, система управления исходными кодами и персональная ответственность за разрабатываемые коды. Поскольку анализаторы интегрируются со средой, разработчики быстро выполняют статический и динамический анализ, не отходя от своего обычного рабочего распорядка. Так что гибридный анализ не будет приносить проблем, если использовать его правильно.
Начать можно с того, что разработчик утром просматривает отчет о результатах ночной компоновки. Сюда будут включены и ошибки компоновки, и результаты статического анализа. Отчет о результатах работы статического анализа включает обнаруженные дефекты вместе с ссылкой на ошибочное место в коде, а также возможное решение данной проблемы. Во многих утилитах все найденные ошибки делятся на 3-4 уровня в зависимости от серьезности. Разработчик может сконцентрироваться на исправлении дефектов высокого и среднего уровней. Но прежде чем использовать код дальше, внесенные изменения надо будет тоже проанализировать [6].
После анализа и корректировки исправленного кода разработчик встраивает его в локальный тестовый образ или исполняемый файл. Далее в работу вступает динамический анализатор, в котором запускаются тесты для проверки нового кода. Также используя информацию анализатора, происходит устранение найденных дефектов. После успешного прохождения статического и динамического анализа можно передавать изменения в систему управления исходными текстами, где измененный код участвует в процессе последующей ночной компоновки (рис.1) [6].
Одной из главных причин инцидентов информационной безопасности являются ошибки и опечатки в исходном коде программы, а также просто плохо написанный код. Все это, чаще всего, приводит к возникновению уязвимостей в программе. В 2020 году 66 % веб-приложений имели уязвимости высо-
кой степени риска, в 2021 году этот показатель немного снизился и составил 62 %. При этом 72 % от общего числа всех найденных уязвимостей связаны с ошибками в коде.
Рис. 1. Алгоритм анализа безопасности исходного кода
Первым вариантом является анализ программного кода на недекларированные возможности и уязвимости в процессе жизненного цикла программного обеспечения. Особо следует отметить необходимость проверки программного кода, содержащегося в транспортных запросах, при переносе данных по ландшафту системы от этапа к этапу. При подобном варианте исследований применение анализа кода позволит снизить процент небезопасных конструкций в коде к моменту эксплуатации программного обеспечения, провести работы по выявлению уязвимостей и недекларированных возможностей без выгрузки и передачи исходного кода на исследования третьей стороне.
Для иллюстрации приведем процесс поиска уязвимостей инъекции кода и SQL-инъекции
(рис. 2).
J:ub In WcbApp HttpServlet
publ i void MainScrvletiHttpServlotflffljuest request, HttpServletResponse response)
String data = request.getParameterC'nasne");
Connection dbCoiinection = lO^tDeCofinectionO; Statement sqlStatement dbConnection-createStatemefltt);
data = tfti ts.Process(data >;
String sqlRequest "select * fro« users where names'" data
I /* rioTCHMManbHafi ynsBwucTt. SOL MKbcrauttt: flaw*« b rvepwennyw data nocTynatoi I K3 MCAOBepenworo kctohhmjo m nociynaoT o aarrpoc k 60+/ ResuitSet resultSct sqlStatemervt executcQucrytsqlRequest);
10 -writeLine< resultSet-getRowi});
Рис. 2. Процесс поиска уязвимостей инъекции кода и SQL- инъекции
На рис. 2 на строке 5 данные получаются из HTTP запроса, который поступает от пользователей при запросе Web-страницы. Например, при запросе страницы "http://example.com/maMname =' or 1='1". Строка or 1='1 попадает в переменную data из объекта request, который содержит HTTP-запрос. Дальше на строке 10 идет вызов функции Process с аргументом data, которая обрабатывает полученную строку. На строке 12 - конкатенация полученной строки data и запроса к базе данных, уже на строке 15 происходит вызов функции запроса к базе данных c результирующим запросом. В результате данных манипуляции получается запрос к базе данных вида: select * from users where name='' or '1'='1'.
Что означает выбрать из таблицы всех пользователей, а не пользователя с определенным именем. Это не является стандартным функционалом и влечет нарушение конфиденциальности, что соответственно означает уязвимость. В результате потенциальный злоумышленник может получить информацию о всех пользователях, а не только о конкретном. Также он может получить данные из других таблиц, например, содержащих пароли и другие критичные данные. А в некоторых случаях - исполнить свой вредоносный код [7].
Как видно, использование обоих анализаторов позволяет не тратить время на полный просмотр кода и поиск ошибок, утилиты даже дают информацию о возможных решениях. Статический анализатор занимается проверкой исходного кода программы, а динамический проверяет программу уже в процессе ее работы и с реальными возможными исходными данными. При гибридном подходе понятно, что оба этих метода дополняют друг друга и позволяют делать программу намного безопаснее.
Список литературы
1. Макконнелл С. Совершенный код. [Электронный ресурс] URL: https://fktpm.ru/file/84-soversennvi-kod.pdf (дата обращения: 10.11.2022).
2. ГОСТ Р 56939-2016. Защита информации. Разработка безопасного программного обеспечения. Общие требования. [Электронный ресурс] URL: https://docs.cntd.ru/document/1200135525 (дата обращения: 10.11.2022).
3. Статический анализ кода. [Электронный ресурс] URL: https://pvs-studio.com/ru/blog/terms/0046 (дата обращения: 10.11.2022).
4. Преимущества и недостатки динамического анализа. [Электронный ресурс] URL: https://studbooks.net/2410652/informatika/ preimuschestva nedostatki dinamicheskogo analiza (дата обращения: 10.11.2022).
5. Динамический анализ кода. [Электронный ресурс] URL: https://pvs-studio.com/ru/blog/terms/0070 (дата обращения: 10.11.2022).
6. Грэм Билл. Использование статического и динамического анализа для повышения качества продукции и эффективности разработки. [Электронный ресурс] URL: https://www.swd.ru/print.php3?pid=828 (дата обращения: 10.11.2022).
7. Миноженко А.А. Обзор методов статического анализа исходного кода для поиска уязвимостей. [Электронный ресурс] URL: https://lib.itsec.ru/articles2/in-ch-sec/obzor-metodov-staticheskogo-analiza-ishodnogo-koda-dlva-poiska-uvazvimostev (дата обращения: 10.11.2022).
8. Анализаторы исходного кода. [Электронный ресурс] URL: https://www.anti-malware.ru/reviews/Code analyzers market overview Russia and world (дата обращения: 10.11.2022).
Баранов Андрей Николаевич, канд. техн. наук, доцент, an111111 @mail.ru, Россия, Тула, Тульский государственный университет,
Баранова Елизавета Михайловна, канд. техн. наук, доцент, elisafine@yandex.ru, Россия, Тула, Тульский государственный университет,
Кулешова Наталья Викторовна, канд. техн. наук, доцент, nata_kyl@mail.ru, Россия, Тула, Тульский государственный университет,
Пелипенко Виктория Алексеевна, бакалавр, elisafine@yandex.ru, Россия, Тула, Тульский государственный университет
APPLICA TION OF HYBRID ANALYSIS TO SEARCH FOR VULNERABILITIES IN THE SOURCE CODE
E.M. Baranova, A.N. Baranov, N.V. Kuleshova, V.A. Pilipenko
The article discusses static and dynamic methods of analyzing the source code, identifies the advantages and disadvantages of the methods, and proposes a model for finding vulnerabilities using a hybrid method.
Key words: code analyzer, static analysis, dynamic analysis, hybrid analysis, code errors, vulnerabilities.
Baranov Andrey Nikolaevich, candidate of technical sciences, docent, an111111@mail.ru, Russia, Tula, Tula State University,
Baranova Elizaveta Mikhailovna, candidate of technical sciences, docent, elisafine@yandex.ru, Russia, Tula, Tula State University,
Kuleshova Natalia Viktorovna, candidate of technical sciences, docent, nata kyl@mail.ru, Russia, Tula, Tula State University,
Pelipenko Victoria Alekseevna, bachelor, elisafine@yandex.ru, Russia, Tula, Tula State University
