Аудит кода

Аудит программного кода - это всесторонний анализ исходного кода в проекте программирования с целью обнаружения ошибок, нарушений безопасности или нарушений соглашений о программировании. Это неотъемлемая часть парадигмы защитного программирования , которая пытается уменьшить количество ошибок до того, как программное обеспечение будет выпущено. Исходный код C и C ++ является наиболее распространенным кодом для аудита, поскольку многие языки более высокого уровня, такие как Python, имеют меньше потенциально уязвимых функций (например, функций, которые не проверяют границы) ^{[ необходима цитата ]} .

Рекомендации [ править ]

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

Уязвимости с высоким риском [ править ]

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

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

Уязвимости с низким уровнем риска [ править ]

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

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

Инструменты [ править ]

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

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

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

См. Также [ править ]

Ссылки [ править ]

^ «Аудит исходного кода - FAQ» . Архивировано из оригинала на 2009-02-10 . Проверено 12 февраля 2008 .
^ ^a ^b ^c "Рекомендации по аудиту исходного кода C" . Архивировано из оригинала на 2008-03-28 . Проверено 12 февраля 2008 .
^ « Статический анализ в конце SDLC не работает. Архивировано 15 октября 2010 г.на Wayback Machine », Уэйн Ариола, SearchSoftwareQuality.com, 22 сентября 2008 г.

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

[guidelines-for-c-source-code-auditing-2] "Рекомендации по аудиту исходного кода C" . Архивировано из оригинала на 2008-03-28 . Проверено 12 февраля 2008 .

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

[1]