Ниже — сжатое руководство по обнаружению и предотвращению XSS и CSRF в веб‑приложении с формами и cookies, список заголовков и CSP‑политик и объяснение ограничений для разработки интерфейса.
Обнаружение (detection)
- Автоматическое тестирование: сканеры/фреймворки (OWASP ZAP, Burp) и фуззинг для форм/параметров.
- Статический анализ: линтеры и SAST для шаблонов/кода (поиск вывода без экранирования).
- Динамическое тестирование: вставка тест‑payload’ов (контекстно‑зависимые) и проверка отклика/DOM.
- Мониторинг браузера: включить CSP reporting (report‑to/report‑uri) — получать нарушения CSP.
- Логирование и WAF: логировать подозрительные входы/ответы, правила WAF для блокировки типовых payload’ов.
- РПМ/анализ поведения: аномалии в поведении пользователей (внезапные переходы, формы с нестандартными referer).
XSS — предотвращение (prevention)
- Контекстное экранирование при выводе: применяйте экранирование, подходящее к месту вывода:
- HTML body text: HTML‑encode.
- HTML attribute: attribute‑encode + кавычки.
- URL/redirect: URL‑encode.
- JavaScript context: JS‑escape или избегать вставки данных внутрь скрипта.
- CSS context: CSS‑escape.
- Использовать безопасные шаблонизаторы/фреймворки с автоэкранированием (React, Vue, Angular, шаблонизаторы серверной стороны) и избегать "raw HTML" или dangerouslySetInnerHTML.
- Если нужно отображать HTML от пользователя — применять белый‑листный санитайзер (DOMPurify, Bleach), удалить скрипты, event‑handler атрибуты, style‑expression и т.п.
- Запрет inline‑скриптов и inline‑стилей (см. CSP ниже) — переносить код в внешние файлы или использовать nonce/hash.
- Уменьшить права JS: избегать использования eval(), new Function() и прочих динамических исполнений.
- HttpOnly для cookies, чтобы JS не мог прочитать сессионный cookie.
- Полное серверное валидация и нормализация входных данных (но валидация не заменяет экранирование при выводе).
CSRF — обнаружение и предотвращение (prevention)
- CSRF токены (per‑session или per‑form): генерировать уникальный токен, хранить в сессии и проверять при запросе на изменение состояния.
- SameSite cookie: установить аттрибут SameSite (Lax/Strict) для снижения кросс‑сайтовых запросов; Lax обычно блокирует опасные POSTs из кросс‑сайтовых контекстов.
- Для API: не полагаться на cookies — использовать токены в Authorization header (Bearer), CORS с проверкой origin и строгими CORS правилами.
- Double submit cookie: при невозможности хранить токен в сессии — отправлять CSRF токен в cookie и в теле/заголовке и сверять.
- Проверка Origin/Referer для критичных действий (более строгая, но зависит от браузерной поддержки и наличия прокси).
- Для форм с file uploads/iframes — дополнительные проверки и ограничение допустимых источников.
Важные HTTP‑заголовки (рекомендуемый набор)
- Content‑Security‑Policy: основная защита XSS (см. ниже по директивам).
- X-Frame-Options: DENY или SAMEORIGIN (лучше использовать CSP frame‑ancestors) — предотвращение clickjacking.
- X-Content-Type-Options: nosniff — предотвращает MIME sniffing.
- Referrer-Policy: настройка отправки Referer (например, no‑referrer‑when‑downgrade или strict‑origin‑when‑cross‑origin).
- Strict‑Transport‑Security: принудительный HTTPS (HSTS).
- Permissions‑Policy (ранее Feature‑Policy): ограничивает доступ к API браузера (geolocation, camera и т.д.).
- Set‑Cookie: Secure; HttpOnly; SameSite=Lax/Strict (в зависимости от прилож)
- X‑XSS‑Protection: устарел, не полагаться.
Content‑Security‑Policy — какие директивы и влияние на разработку
- Базовые директивы: default-src, script-src, style-src, img-src, font-src, connect-src, frame‑ancestors, object-src, base-uri, sandbox.
- Рекомендуемая минимальная политика (приближённо): запрещать всё по умолчанию и разрешать только нужные источники, например, default‑src 'none'; script‑src 'self' 'nonce-' (или хэши); style‑src 'self' 'nonce-' (или hash); connect‑src только API домены; img‑src только доверенные CDN/data: если нужно.
- Nonces vs hashes:
- Nonce: генерируется уникально для каждого ответа, требуется вставлять атрибут nonce в разрешённые теги . Подходит для динамических inline скриптов, но усложняет шаблоны и кэширование.
- Hash: фиксированный hash содержимого скрипта; хорош для статических inline скриптов (позволяет кэширование), но неудобен при динамике.
- 'unsafe-inline' и 'unsafe‑eval' увеличивают риск XSS — избегать.
- 'strict‑dynamic': при использовании nonces/hashes может разрешать загрузку доверенных скриптов, но требует осторожности и обычно совместим с CSP level 3.
- frame‑ancestors: контролирует кто может фреймить ваш сайт (альтернатива X‑Frame‑Options).
- sandbox: можно наложить дополнительные ограничения на встраиваемое содержимое (например, запрет форм, скриптов).
- report‑to / report‑uri: включите сбор нарушений CSP для оперативного обнаружения попыток XSS.
- Ограничения для разработки:
- Inline scripts и inline event‑handlers (onclick и т.п.) не будут работать без явного разрешения (nonce/hash или unsafe‑inline). Требуется перенос логики в внешние файлы или добавлять nonces.
- Библиотеки/виджеты, требующие eval() или inline styles, могут сломаться (нужно искать версии без eval/inline или добавить исключения).
- Использование nonces мешает кэшированию HTML на CDN (нужна серверная вставка nonce).
- При строгих connect-src нужно явно добавлять адреса API/WebSocket/analytics; иначе XHR/fetch/WS будут блокироваться.
- Для CSS: inline styles будут блокированы без разрешения — стили нужно выносить в файлы или использовать nonce на .
- Для интеграций (третьи сервисы, analytics, виджеты) потребуется согласование: либо добавить их host в CSP, либо использовать прокси/сервисную интеграцию.
Практические рекомендации (шаги внедрения)
1. Включите базовые заголовки безопасности (HSTS, nosniff, frame‑ancestors/X‑Frame‑Options, Referrer‑Policy, Permissions‑Policy).
2. Включите HttpOnly + Secure + SameSite для cookies.
3. Реализуйте серверные проверки CSRF (токены) для state‑changing запросов; для API — переход на заголовок Authorization.
4. Добавьте CSP в режиме report‑only сначала, соберите отчёты, исправьте сломанные интеграции, затем включите блокирующий режим.
5. Переходите на контекстное экранирование/санитайзеры, удалите inline обработчики и eval‑зависимости.
6. Проводите регулярные автоматические и ручные тесты (pen‑test) и мониторинг CSP нарушений.
Коротко о приоритетах
- Самое эффективное против XSS: экранирование по контексту + строгая CSP без unsafe‑inline/unsafe‑eval + санитайзер для допустимого HTML.
- Самое эффективное против CSRF: CSRF токены + SameSite cookie + проверка Origin для критичных действий.
Если нужно — могу привести конкретную примерную CSP‑политику и примеры кода для вставки nonce/проверки CSRF токена в вашем стеке (укажите стек).