Методы безопасного анализа кода

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

Автоматизированные инструменты SAST (Semgrep, SonarQube, CodeQL) быстро обнаруживают известные шаблоны, но пропускают недостатки бизнес-логики, сложные уязвимости в нескольких компонентах и проблемы, зависящие от контекста. Ручная проверка выявляет то, что пропускает автоматизация. Необходимы оба подхода.

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

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

Решения безопасности принимаются на границах доверия — там, где данные переходят из менее доверенного контекста (HTTP-запроса) в более доверенный (базу данных, OS). Каждый переход через границу доверия должен сопровождаться проверкой, очисткой или авторизацией данных.

Отмечайте использование: eval(), exec(), system(), shell_exec(), innerHTML, dangerouslySetInnerHTML, deserialize(), pickle.loads(), Runtime.exec(), ProcessBuilder, XML-парсеров, в которых не отключено раскрытие сущностей, а также непосредственного использования криптографических примитивов вместо высокоуровневых интерфейсов.

Проверьте следующее: защищена ли каждая конфиденциальная конечная точка аутентификацией? Проверяется ли авторизация на стороне сервера для каждого действия? Может ли пользователь получить доступ к данным другого пользователя, изменив параметр ID (IDOR)? Защищены ли конфиденциальные операции от CSRF?

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

Отмечайте использование MD5 или SHA-1 для хеширования паролей (используйте bcrypt или Argon2), жестко заданных симметричных ключей или IV, шифрования в режиме ECB (используйте GCM или CBC с HMAC), собственных реализаций криптографии и генераторов случайных чисел, не являющихся криптографически защищенными.

Проверьте package.json и pom.xml на наличие устаревших зависимостей. Проверьте конфигурацию приложения на включенный в рабочей среде режим отладки, подробные страницы ошибок, учетные данные администратора в файлах конфигурации и отсутствующие заголовки безопасности (HSTS, CSP, X-Frame-Options).

Правила Semgrep сопоставляют синтаксические шаблоны с учетом семантики. Пишите пользовательские правила для специфичных шаблонов вашей кодовой базы. CodeQL рассматривает код как данные: с помощью запросов к AST можно находить потоки данных от источников к приемникам в разных файлах и вызовах методов.

Что такое уязвимость IDOR и где следует искать ее при проверке кода?

Эффективная проверка безопасности кода объединяет составление карты точек входа, трассировку потоков данных, анализ границ доверия, обнаружение опасных интерфейсов и автоматизированные инструменты SAST. Она выявляет проблемы безопасности, которые пропускает функциональная проверка, особенно недостатки бизнес-логики и незаметные пробелы в авторизации.