Чтение кода вручную — трудоемкий процесс. Он также подвержен ошибкам, так как легко упустить важные детали. Нам, разработчикам и тестерам на проникновение, необходимо найти способ автоматизировать этот процесс. SAST — это метод, который может помочь нам в решении этой задачи.
SAST – это не панацея. Его можно использовать только в случаях использования с доступом к исходному коду для проектов с открытым исходным кодом или тестирования на проникновение «белого ящика». Тем не менее, это может помочь вам найти некоторые легко висящие плоды и сэкономить время.
Статическое тестирование безопасности приложений (SAST) — это разновидность статического анализа кода, используемая для повышения безопасности и надежности кода. SAST обнаруживает старые зависимости, обнаружение секретов, логические ошибки, приводящие к уязвимостям, и многое другое. SAST включает в себя тестирование, которое вторично влияет на кибербезопасность, например, на сложность визуального кода, неоднозначность кода и неинтуитивные методы, которые могут привести к уязвимостям.
Инструменты SAST обычно представляют собой средства сопоставления шаблонов регулярных выражений на стероидах, которые ищут известные уязвимости в коде. Например, инструмент SAST может искать использование eval
, exec
или pickle
в коде Python. Эти функции можно использовать для выполнения произвольного кода.
Я бы разделил свой подход к SAST на три категории:
Обнаружение уязвимостей : я использую такие инструменты, как Semgrep , Bandit , Nodejsscan, чтобы найти векторы атак в коде. Обычно вы можете найти легко висящие плоды, такие как несанкционированные входные данные, плохая криптография или уязвимые библиотеки. Кстати, в версии Semgrep PRO правил больше; бесплатно, если на проекте не более 10 разработчиков.
Обнаружение секретов : Gitleaks , Trufflehog или Grep могут помочь вам найти секреты в коде. Это важно, поскольку секреты можно использовать для повышения привилегий или доступа к конфиденциальным данным. Обычно в коде хранятся строки подключения к базе данных, ключи API или пароли.
Неправильные конфигурации . Такие инструменты, как Checkov или Trivy, могут помочь вам обнаружить неправильные конфигурации. Неправильные конфигурации обычно находятся в файлах «инфраструктура как код» (IaC), но также могут быть и в самом коде. Примером может служить неправильно настроенный файл docker-compose, который предоставляет доступ к базе данных в Интернете. Для сканирования Dockerfiles я рекомендую комбинацию Hadolint и Grype.
Дополнительная информация: https://dkb-zh.gitlab-pages.ics.muni.cz/vulnerability-management/web-guides-external/docs/guide_iac_sast/#docker .
Инструменты SAST не идеальны. Они дадут вам ложноположительные и ложноотрицательные результаты. **Однако это экономит много времени по сравнению со случайным использованием некоторых приложений. Я использовал инструменты SAST в своих заданиях и соревнованиях по тестированию на проникновение. Это помогло мне начать работу с кодовой базой и дало несколько подсказок о том, где искать уязвимости.
Рекомендую начать с Hack The Box . Эта платформа предлагает такие задачи, как получение исходного кода и поиск уязвимостей. Затем используйте их на реальной машине. Это отличный способ научиться использовать инструменты SAST на практике.
Или, если вы разработчик, вы можете использовать инструменты SAST в своем конвейере CI/CD. Таким образом, вы сможете привыкнуть к инструментам и их результатам. Одновременно вы повысите безопасность вашего приложения.
Я подготовил список руководств, которые помогут вам начать работу с SAST и обнаружением секретов. Эти руководства написаны в рамках моей диссертации и являются отличной отправной точкой для всех, кто интересуется инструментами SAST.
Обнаруживая секреты, помните: это не секрет, если его знают хакеры. Даже опытные разработчики могут случайно передать пароли или строки подключения в удаленную систему управления версиями. В этом руководстве с помощью различных инструментов предлагаются быстрые и простые способы снижения этого риска.
В этом руководстве основное внимание уделяется пониманию обнаружения секретов с использованием перехватчиков предварительной фиксации и конвейеров CI/CD. Хотя код в основном ориентирован на GitLab, последний раздел также будет посвящен GitHub.
В этом руководстве подробно описаны шаги по запуску статического тестирования безопасности приложений (SAST) в GitLab. SAST — это процесс, который использует статический анализ кода для выявления потенциальных уязвимостей.
В этой шпаргалке представлены полезные инструменты для сканирования артефактов инфраструктуры как кода (IaC) и приведены примеры их интеграции в ваш конвейер CI/CD.
Я создал собственный инструмент в Golang, который помогает мне быстро сопоставлять регулярные выражения с огромными базами кода.
Существует бесконечный компромисс между точностью и дисперсией.
Предположим, вам нужно больше разнообразия и вы не против большего количества проверок вручную. В этом случае вы можете попробовать RegFinder , который похож на grep
, но больше подходит для обнаружения секретов (быстрее в больших репозиториях, четкий вывод, игнорируя некоторые расширения файлов). Или вы можете использовать grep напрямую. Наиболее ценными являются регулярные выражения в репозитории, а не инструмент, который вы будете использовать.
grep -n -r your_app/ -Ef regex_dir/general.txt
Или
./regfinder.elf -d your_app/ -f regex_dir/general.txt
Расширить существующие шаблоны регулярных выражений несложно. Этот инструмент непригоден для автоматизированных конвейеров. Однако это пригодится, если вам нужно найти нестандартный секрет или при других оценках, таких как проверки безопасности, где ожидается больше ручной работы.
Прокомментируйте, если у вас есть большой опыт работы с другими инструментами . Спасибо за чтение.