🔍 Нашли уязвимость — поищите ее в других сервисах
Есть одна вещь, над которой мало кто задумывается после обнаружения очередной уязвимости. Это поиск проблем такого же класса в других сервисах компании.
Ведь зачастую разработчики совершают одни и те же ошибки. Иногда они просто переиспользуют уязвимый код, иногда невнимательно читают документацию. Причины могут быть разные, а результат всегда один: много похожих уязвимостей в совершенно разных приложениях.
Есть несколько вариантов решения такой проблемы:
1️⃣ Организовать ручной поиск. Не требует никаких пререквизитов и прекрасно работает со специфичными для определенного функционала уязвимостями. Например, с Race Condition, Blind XSS или отсутствием рейт-лимитов.
2️⃣ Разобраться в коде и написать новое правило для SAST. Хорошо себя показывает, когда четко понятна ошибка на уровне кода. Таким образом обычно автоматизируют поиск небезопасных конструкций определенного языка или библиотеки: начиная от SQL-инъекций и заканчивая XXE. Здесь на помощь приходит Semgrep с его очень низким порогом входа для написания собственных правил.
3️⃣ Воспользоваться DAST и написать собственный сценарий или шаблон для тестирования. Идеально подходит, если есть простой пейлоад и понятна реакция уязвимого приложения. Например, так можно автоматизировать поиск различных мисконфигов (публично доступный Spring Boot Actuator или Swagger документация). Здесь поможет Nuclei с его шаблонами. Можно также попробовать OWASP ZAP с его скриптами.
Данный подход существенно улучшит ваши процессы и позволит не только находить больше уязвимостей, но и отлавливать их уже на стадии разработки во время написания кода или запуска тестов.
#processes #vulnerabilities #tools
Есть одна вещь, над которой мало кто задумывается после обнаружения очередной уязвимости. Это поиск проблем такого же класса в других сервисах компании.
Ведь зачастую разработчики совершают одни и те же ошибки. Иногда они просто переиспользуют уязвимый код, иногда невнимательно читают документацию. Причины могут быть разные, а результат всегда один: много похожих уязвимостей в совершенно разных приложениях.
Есть несколько вариантов решения такой проблемы:
1️⃣ Организовать ручной поиск. Не требует никаких пререквизитов и прекрасно работает со специфичными для определенного функционала уязвимостями. Например, с Race Condition, Blind XSS или отсутствием рейт-лимитов.
2️⃣ Разобраться в коде и написать новое правило для SAST. Хорошо себя показывает, когда четко понятна ошибка на уровне кода. Таким образом обычно автоматизируют поиск небезопасных конструкций определенного языка или библиотеки: начиная от SQL-инъекций и заканчивая XXE. Здесь на помощь приходит Semgrep с его очень низким порогом входа для написания собственных правил.
3️⃣ Воспользоваться DAST и написать собственный сценарий или шаблон для тестирования. Идеально подходит, если есть простой пейлоад и понятна реакция уязвимого приложения. Например, так можно автоматизировать поиск различных мисконфигов (публично доступный Spring Boot Actuator или Swagger документация). Здесь поможет Nuclei с его шаблонами. Можно также попробовать OWASP ZAP с его скриптами.
Данный подход существенно улучшит ваши процессы и позволит не только находить больше уязвимостей, но и отлавливать их уже на стадии разработки во время написания кода или запуска тестов.
#processes #vulnerabilities #tools
💫 Go Vulnerability Management и Govulncheck
Создатели языка Go рассказали о своем новом проекте Go Vulnerability Management и представили govulncheck — утилиту для проверки используемых зависимостей на предмет наличия известных уязвимостей.
В отличие от аналогов она не просто сканирует файл с перечнем всех импортируемых зависимостей, чтобы определить, содержат ли они уязвимости, но и делает дополнительный шаг, проверяя, вызывается уязвимый код или нет. Это позволяет убрать шум из многочисленных нерелеватных уязвимостей и сконцентрироваться на исправлении реальных проблем.
Чтобы реализовать такую киллер-фичу авторам пришлось создать свою собственную базу уязвимостей и организовать процессы таким образом, чтобы для каждой проблемы были отмечены все уязвимые функции.
Ранее такой подход я встречал только у Checkmarx и их инструмента CxSCA (подробнее можно прочитать вот тут). Но теперь эта тема становится все популярнее. Совсем недавно ребята из r2c анонсировали Semgrep Supply Chain с очень похожим функционалом.
Но это все — коммерческие инструменты, а вот govulncheck может использовать абсолютно любой Go разработчик. Это определенно прорыв для всей экосистемы данного языка. Надеюсь, что-то похожее мы скоро увидим и в других экосистемах.
#tools #dependencies #vulnerabilities
Создатели языка Go рассказали о своем новом проекте Go Vulnerability Management и представили govulncheck — утилиту для проверки используемых зависимостей на предмет наличия известных уязвимостей.
В отличие от аналогов она не просто сканирует файл с перечнем всех импортируемых зависимостей, чтобы определить, содержат ли они уязвимости, но и делает дополнительный шаг, проверяя, вызывается уязвимый код или нет. Это позволяет убрать шум из многочисленных нерелеватных уязвимостей и сконцентрироваться на исправлении реальных проблем.
Чтобы реализовать такую киллер-фичу авторам пришлось создать свою собственную базу уязвимостей и организовать процессы таким образом, чтобы для каждой проблемы были отмечены все уязвимые функции.
Ранее такой подход я встречал только у Checkmarx и их инструмента CxSCA (подробнее можно прочитать вот тут). Но теперь эта тема становится все популярнее. Совсем недавно ребята из r2c анонсировали Semgrep Supply Chain с очень похожим функционалом.
Но это все — коммерческие инструменты, а вот govulncheck может использовать абсолютно любой Go разработчик. Это определенно прорыв для всей экосистемы данного языка. Надеюсь, что-то похожее мы скоро увидим и в других экосистемах.
#tools #dependencies #vulnerabilities
🚨 Исправили критическую уязвимость — проверьте логи
Многие думают, что исправление уязвимости - это заключительный этап работы с ней, после которого можно выдохнуть. Но некоторые ошибки безопасности, в особенности высокой степени критичности, требуют дополнительных действий.
Один из важнейших этапов работы с критическими уязвимостями — это поиск следов эксплуатации. Ведь важно не только быстро устранить серьезную проблему, но и убедиться, что вам больше ничего не угрожает.
А для этого необходимо заранее позаботиться о централизованном сборе логов как отдельных приложений, так и инфраструктуры в целом. Причем одного лишь сбора будет недостаточно. Важно сформировать политику логгирования, где будут определены как минимум следующие составляющие:
📌 Типы сохраняемых событий (попытки аутентификации, доступ к чувствительным данным, …)
📌 Набор сохраняемых параметров (дата и время, источник, тип события, …)
📌 Срок хранения (для разного рода событий он может быть разным)
В противном случае может оказаться, что либо нужных логов не будет, либо они будут бесполезны.
#processes #vulnerabilities
Многие думают, что исправление уязвимости - это заключительный этап работы с ней, после которого можно выдохнуть. Но некоторые ошибки безопасности, в особенности высокой степени критичности, требуют дополнительных действий.
Один из важнейших этапов работы с критическими уязвимостями — это поиск следов эксплуатации. Ведь важно не только быстро устранить серьезную проблему, но и убедиться, что вам больше ничего не угрожает.
А для этого необходимо заранее позаботиться о централизованном сборе логов как отдельных приложений, так и инфраструктуры в целом. Причем одного лишь сбора будет недостаточно. Важно сформировать политику логгирования, где будут определены как минимум следующие составляющие:
📌 Типы сохраняемых событий (попытки аутентификации, доступ к чувствительным данным, …)
📌 Набор сохраняемых параметров (дата и время, источник, тип события, …)
📌 Срок хранения (для разного рода событий он может быть разным)
В противном случае может оказаться, что либо нужных логов не будет, либо они будут бесполезны.
#processes #vulnerabilities