Аудит кода

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

Рекомендации

При аудите программного обеспечения каждый критический компонент должен проверяться отдельно и вместе со всей программой. Рекомендуется сначала найти уязвимости с высоким уровнем риска , а затем перейти к уязвимостям с низким уровнем риска. Уязвимости между высоким и низким уровнем риска обычно существуют в зависимости от ситуации и того, как используется рассматриваемый исходный код. Тестирование на проникновение приложений пытается выявить уязвимости в программном обеспечении, запуская как можно больше известных методов атаки на вероятных точках доступа в попытке вывести из строя приложение. ^[1] Это распространенный метод аудита, который можно использовать для выяснения наличия каких-либо конкретных уязвимостей, но не для определения их местонахождения в исходном коде. Некоторые утверждают, что методы аудита в конце цикла, как правило, перегружают разработчиков, в результате чего у команды остается длинный список известных проблем, но мало реальных улучшений; в этих случаях в качестве альтернативы рекомендуется метод оперативного аудита.Примером упреждающего подхода является бесплатная служба аудита кода, предлагаемая GooApps, целью которой является выявление и устранение уязвимостей на ранних этапах процесса разработки, чтобы обеспечить успех мобильных приложений. ^[2]

Уязвимости высокого риска

Некоторые распространенные уязвимости высокого риска могут существовать из-за использования:

Функции, не проверяющие границы (например, strcpy , sprintf , vsprintf и sscanf ), которые могут привести к переполнения буфера. уязвимости ^[3]
Манипулирование указателями буферов, которые могут помешать последующей проверке границ, например: if ((bytesread = net_read(buf,len)) > 0) buf += bytesread; ^[3]
Вызовы типа execve (), конвейеры выполнения, system() и подобные вещи, особенно при вызове с нестатическими аргументами. ^[3]
Проверка ввода, например (в SQL): statement := "SELECT * FROM users WHERE name = '" + userName + "';" является примером SQL-инъекции. уязвимости
Функции включения файлов, например (в PHP): include($page . '.php'); является примером удаленного включения файлов. уязвимости
Для библиотек, которые могут быть связаны с вредоносным кодом, возврат ссылки на внутреннюю изменяемую структуру данных (запись, массив). Вредоносный код может попытаться изменить структуру или сохранить ссылку, чтобы наблюдать за будущими изменениями.

Уязвимости с низким уровнем риска

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

Уязвимости кода на стороне клиента, не затрагивающие серверную часть (например, межсайтовый скриптинг )
Перечисление имени пользователя
Обход каталога
Чувствительные ключи API

Инструменты

Инструменты аудита исходного кода обычно ищут общие уязвимости и работают только для определенных языков программирования . Такие автоматизированные инструменты можно использовать для экономии времени, но на них не следует полагаться при проведении углубленного аудита. Рекомендуется применять такие инструменты как часть подхода, основанного на политике. ^[4]

Зависимость от требований

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

См. также

Ссылки

^ «Аудит исходного кода — часто задаваемые вопросы» . Архивировано из оригинала 10 февраля 2009 г. Проверено 12 февраля 2008 г.
^ «Бесплатный аудит кода приложений: обеспечение успеха вашего мобильного приложения» . Проверено 12 июня 2024 г.
^ Перейти обратно: ^а ^б ^с «Руководство по аудиту исходного кода C» . Архивировано из оригинала 28 марта 2008 г. Проверено 12 февраля 2008 г.
^ « Статический анализ в конце SDLC не работает. Архивировано 15 октября 2010 г. на Wayback Machine », Уэйн Ариола, SearchSoftwareQuality.com, 22 сентября 2008 г.

[source-code-audit-faq-1] «Аудит исходного кода — часто задаваемые вопросы» . Архивировано из оригинала 10 февраля 2009 г. Проверено 12 февраля 2008 г.

[2] «Бесплатный аудит кода приложений: обеспечение успеха вашего мобильного приложения» . Проверено 12 июня 2024 г.

[guidelines-for-c-source-code-auditing-3] Перейти обратно: ^а ^б ^с «Руководство по аудиту исходного кода C» . Архивировано из оригинала 28 марта 2008 г. Проверено 12 февраля 2008 г.

[4] « Статический анализ в конце SDLC не работает. Архивировано 15 октября 2010 г. на Wayback Machine », Уэйн Ариола, SearchSoftwareQuality.com, 22 сентября 2008 г.

[1]

[2]

[3]

[4]