Аудит кода - Code audit

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

Руководящие указания

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

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

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

  • Функции проверки ограничений (например, strcpy, спринт, vsprintf и sscanf ), что может привести к переполнение буфера уязвимость [2]
  • Манипуляции с указателями буферов, которые могут помешать более поздней проверке границ, например: если ((bytesread = net_read (buf, len))> 0) buf + = bytesread; [2]
  • Звонит как Execve (), конвейеры выполнения, system () и подобные вещи, особенно при вызове с нестатическими аргументами [2]
  • Проверка ввода, например (в SQL): инструкция: = "ВЫБРАТЬ * ОТ пользователей WHERE name = '" + userName + "';" является примером SQL-инъекция уязвимость
  • Функции включения файлов, например (в PHP): включить ($ page. '.php'); является примером Включение удаленного файла уязвимость
  • Для библиотек, которые могут быть связаны с вредоносным кодом, возвращение ссылки на внутреннюю изменяемую структуру данных (запись, массив). Вредоносный код может попытаться изменить структуру или сохранить ссылку для наблюдения за будущими изменениями.

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

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

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

Инструменты

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

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

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

Смотрите также

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

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