Главная мысль
Покажите потоки данных и границы доверия на схеме, определите для каждого риска проверяемую меру защиты и повторите проверку после исправления.
Моделируйте угрозы с этапа проектирования
Составьте карту компонентов, ценных активов, потоков данных и границ доверия. Для каждой границы и операции спросите команду: «Что может пойти не так?». STRIDE помогает проверить подмену личности, нарушение целостности, отрицание совершённых действий, раскрытие данных, отказ в обслуживании и повышение привилегий; дерево атак раскрывает пути к цели, а сценарий злоупотребления показывает вредное использование штатной функции. Выберите метод под систему, обоснуйте вероятность и влияние, назначьте ответственного и меру снижения риска. Обновляйте модель при изменении архитектуры и зависимостей.
Определите актив и поток
Например, изобразите путь данных аккаунта от браузера через API к базе.
Проверьте границу
Запишите риски идентификации, разрешений, недоверенного ввода и компрометации компонентов.
Проверьте меру защиты тестом
Для каждого высокого риска назначьте ответственного, меру снижения риска и повторную проверку.
Базовая защита от внедрения кода, SQLi и RCE
Внедрение кода возникает, когда недоверенные данные интерпретируются как код SQL, командной оболочки или другого интерпретатора. Например, если текст имени пользователя конкатенируется с SQL-запросом входа, ввод может стать частью синтаксиса; в параметризованном запросе он остаётся значением, а не кодом. Добавьте список допустимых значений и проверку типов на сервере. По возможности не вызывайте командную оболочку; иначе передавайте аргументы отдельно и ограничивайте привилегии. При десериализации принимайте только ожидаемые типы и не создавайте произвольные объекты; проверяйте безопасность памяти и границы буферов. RCE позволяет выполнять код в скомпрометированном процессе, поэтому обновляйте открытые сервисы, ограничивайте права и исходящие соединения, проверяйте обнаружение и восстановление.
SQLi с получением данных по тому же каналу
Результат возвращается по каналу атаки, например через сообщения об ошибках или результаты запросов с UNION.
Слепая SQL-инъекция
Когда результат не виден напрямую, сведения выводят по разнице ответов на истинное и ложное условие или по задержке.
SQLi с отдельным каналом вывода
Данные могут уходить через отдельное DNS- или HTTP-соединение сервера базы; ограничивайте исходящие подключения и права базы данных.
Разные виды тестирования находят разные слабые места
SAST находит потенциально опасные конструкции в коде без запуска приложения; ложные срабатывания и недостижимые пути нужно проверять вручную. SCA сверяет зависимости с известными уязвимостями, а SBOM описывает компоненты приложения. DAST отправляет запросы работающему приложению и ищет проблемы аутентификации, конфигурации, межсайтового скриптинга (XSS) и внедрения кода; охват ограничен проверенными маршрутами и ролями. IAST может сочетать наблюдение во время выполнения с контекстом кода, но видит только протестированные сценарии. OWASP Top 10 — полезная отправная точка; проверяйте риски управления доступом, внедрения кода, криптографии, XSS и ошибок конфигурации с учётом системы. Модульные тесты легче повторять, если они не зависят от внешних сервисов и БД; интеграционные тесты проверяют взаимодействие модулей и передачу событий аудита. Фаззинг ищет граничные случаи на неожиданных входных данных. Для теста на проникновение определите объём информации, предоставляемой исполнителю: «чёрный», «белый» или «серый ящик». Отдельно согласуйте системы, разрешённые действия и границы теста. Сканирование и тест на проникновение дополняют друг друга.
Оценивайте защиту во время выполнения с учётом приложения
RASP отслеживает контекст выполнения внутри приложения и может блокировать запрос или операцию по настроенным правилам. WAF проверяет HTTP-трафик до его передачи приложению. В пилоте проверьте поддержку вашего языка и фреймворка, режим блокировки, задержку, ложные срабатывания и процесс обновления. Используйте реальные сценарии приложения и контролируемые имитации атак; обнаруженные ошибки кода и конфигурации исправляйте отдельно.
| Средство защиты | Где действует | Что проверить |
|---|---|---|
| SAST / SCA | При изменении кода и зависимостей | Охват, ложные срабатывания, ответственный за исправление |
| DAST / тест на проникновение | На работающем сервисе и его интерфейсах | Охват ролей и маршрутов, безопасная область теста |
| WAF / RASP | Перед приложением / внутри среды его выполнения | Совместимость, задержка, блокировка и аудит |
Управляйте конфигурацией и облачными мерами защиты как кодом
Замените пароли по умолчанию, отключите неиспользуемые службы и порты, сократите права доступа и IAM до минимума, защищайте данные при передаче и хранении. До развёртывания проверяйте код инфраструктуры (IaC): облачные хранилища, группы безопасности, API и правила доступа. Регулярно сравнивайте рабочую конфигурацию с кодом, чтобы обнаруживать отклонения. Захват учётных записей, избыточное предоставление данных и открытые API могут затронуть несколько облачных сред. Подход CNAPP может объединять оценку конфигурации (CSPM), защиту рабочих нагрузок (CWPP), управление разрешениями (CIEM) и сканирование IaC. Защита веб-приложений и API (WAAP) может сочетать WAF, защиту от ботов и DDoS с ограничением частоты запросов API. Это категории решений: проверяйте охват конкретного продукта. С учётом модели сервиса зафиксируйте ответственность провайдера и команды за приложения, учётные записи, сеть и данные.
Отслеживайте выявленную проблему до исправления и повторного теста
Для каждой выявленной проблемы укажите затронутый актив, подтверждающие данные, уровень риска, ответственную команду, безопасную временную меру и постоянное исправление. Определяйте приоритет по вероятности эксплуатации и возможному ущербу, а не только по оценке инструмента. После исправления повторите тот же сценарий, добавьте связанные проверки в CI и при необходимости обновите модель угроз. Для критичных систем проверяйте аутентификацию, права доступа и потоки данных автоматическими тестами и независимым анализом.