Краткая архитектурная стратегия — «multiple layers» (разделение обязанностей + централизованные библиотеки + runtime-детекция). Ниже — практики по каждой категории уязвимостей и общие меры (код, сервер/инфраструктура, автоматизация тестирования, мониторинг).
Общие принципы (основа)
- Централизовать валидацию/экранирование в библиотеке/middleware, не дублировать по компонентам.
- По возможности использовать фреймворковые механизмы (ORM, шаблонизаторы с авто-экранированием, CSRF-middleware).
- Принцип наименьших привилегий для БД и сервисных аккаунтов.
- Жёсткая CORS-политика и явные Content-Type/charset (UTF-8).
- TLS + HSTS + Secure/HttpOnly/SameSite для cookie.
- WAF + RASP/IDS для runtime-детекции + централизованный лог и алерты.
- CI/CD: SAST/DAST блоки, security-gates и автоматические тесты безопасности.
SQL-инъекции — предотвращение и обнаружение
- Код и дизайн:
- Использовать параметризованные запросы / подготовленные выражения (prepared statements) или ORM query-builders. Никогда не конкатенировать пользовательские данные в SQL.
- Для динамической части SQL использовать allow-list (разрешённые имена колонок/таблиц) и безопасные API (напр., map от внешнего ключа к заранее определённой конструкции), а не подстановку raw-строк.
- Ограничивать выдаваемые права БД (только SELECT/INSERT/UPDATE/DELETE, без админских привилегий).
- Лимитировать время и объём выполнения запросов на уровне БД/прокси (timeout, max_rows).
- Конфигурация серверов/БД:
- Отключать детальные стек-трейсы в ответах клиенту; логировать их на сервере.
- Включить query logging и аномал-детекцию (например, необычные частые одинаковые запросы, длинные строки).
- Использовать DB-firewall/SQL-proxy (если доступно) для блокировки известных паттернов.
- Автоматизированное тестирование и детекция:
- SAST: проверять конкатенацию строк при формировании SQL, использование execute("..."+user) и т.п.
- DAST/fuzzing: автоматические сканы SQLMap, ZAP/ Burp Suite в pipeline; тестовые payload’ы.
- Unit/integration тесты: симулировать вредоносные входы и проверять, что запросы проходят как параметризованные (или что ORM генерирует bind-параметры).
- Runtime: мониторить ошибочные SQL-ответы/исключения и метрики неуспешных парных запросов.
XSS — предотвращение и обнаружение
- Код и дизайн:
- Всегда делать контекстно-зависимое экранирование выходных данных: HTML-элемент, HTML-атрибут, JS-строка, URL, CSS — разные энкодеры. Использовать проверенные библиотеки/шаблонизаторы с авто-экранированием.
- Для HTML-контента, разрешающего некоторый HTML (WYSIWYG), применять серверную безопасную санитизацию (white-list) с библиотеками типа DOMPurify (или эквивалент) и ограничивать теги/атрибуты.
- Никогда не вставлять непроверенные данные в inline-скрипты или event-атрибуты. Избегать JSONP.
- Устанавливать cookie с HttpOnly, чтобы JS не мог получить сессионные cookie.
- Конфигурация серверов/HTTP:
- Content-Security-Policy: использовать строгую CSP, по возможности с nonce/hashes для разрешённых inline-скриптов; запретить unsafe-inline, ограничить источники скриптов/стилей.
- Установить X-Content-Type-Options: nosniff и правильный Content-Type для ответов.
- Отключить отображение подробных ошибок и включить безопасные заголовки.
- Автоматизированное тестирование:
- SAST: поиск вывода необработанных данных в шаблоны, встраивание данных в JS/HTML без энкодинга.
- DAST: автоматические сканеры XSS (ZAP, Burp) + фаззинг параметров и заголовков.
- Unit/UI тесты: тесты рендеринга с payload-ами, проверка, что вывод экранирован и что CSP блокирует инъекцию (CSP-отчёты).
- CI: включить клиентские интеграционные тесты, которые проверяют реагирование браузера на потенциально вредоносные ответы.
CSRF — предотвращение и обнаружение
- Код и дизайн:
- Для cookie-базированной аутентификации — использовать синхронизирующие CSRF-токены (synchronizer token pattern): уникальный per-session/per-request токен в hidden-поле форм и проверку на сервере.
- Для API — предпочитать схемы авторизации, не зависящие от cookie (Bearer tokens в Authorization header). Браузер не автоматически выставляет их, поэтому CSRF риск снижен.
- Проверять Origin/Referer для state-changing запросов (POST/PUT/DELETE) и отклонять запросы с недопустимых источников.
- Использовать SameSite=strict или lax для cookie; для SPA — рассмотреть double-submit cookie + header проверку.
- Конфигурация серверов/инфраструктуры:
- Явно запрещать unsafe CORS; разрешать конкретные origin и методы; не включать Access-Control-Allow-Credentials если не нужно.
- Для критичных операций требовать дополнительную валидацию (re-auth, MFA, подтверждение паролем).
- Автоматизированное тестирование:
- SAST: проверять наличие проверки CSRF-токена в контроллерах/эндпоинтах, поиск отключённых CSRF фильтров.
- DAST: автоматические проверки CSRF (ZAP имеет модуль, имитирующий CSRF-атаки).
- Integration тесты: убедиться, что state-changing действия без корректного токена/заголовка отклоняются; тестировать Origin/Referer проверки.
Мониторинг, логирование и реагирование
- Централизованные логи запросов, ошибок БД, WAF/IDS-алерты; хранить достаточно контекста (хедеры, тело, IP) при соблюдении GDPR.
- Настраиваемые алерты при всплесках ошибочных запросов, повторяющихся подозрительных payload’ов, увеличении ошибок БД.
- Регулярные pentest + тестовые сценарии инцидента в playbook.
CI/CD и автоматизация
- Включить SAST (правила по SQL-конкатенации, output-escaping, отсутствие CSRF-проверок) как blocking check.
- DAST в staging перед релизом; регресс-тесты для найденных уязвимостей.
- Dependency scanning (OWASP Dependency-Check, Snyk) для библиотек.
- Unit/integration тесты безопасности + fuzzing API в pipeline.
- Автоматические развертывания WAF-правил и CSP-отчётов для оперативной настройки.
Краткий чеклист для внедрения (архитектурные шаги)
- Ввести библиотеку/мидлвар для централизованной валидации и контекстного экранирования.
- Переход на параметризованные запросы/ORM, запрет raw-SQL в коде (SAST-правило).
- Включить CSRF-middleware или использовать header-based token для API.
- Наладить CSP с nonce/hash и строгие security-headers.
- Установить Secure/HttpOnly/SameSite на cookie и ужесточить CORS.
- Развернуть WAF + runtime мониторинг + CI SAST/DAST/Dependency scans.
- Документировать и тестировать реакции на инциденты.
Если нужно, могу дать готовые примеры кода для конкретного стека (например, Java/Spring, Node/Express, Python/Django) или набор SAST/DAST правил и тест-кейсов.