Рассмотрите безопасность веб-приложения с точки зрения программирования: объясните XSS, CSRF, SSRF и укажите конкретные кодовые приёмы и архитектурные решения для снижения рисков
XSS (Cross‑Site Scripting) - Что это: внедрение и исполнение злого JavaScript в браузере жертвы через уязвимый вывод данных. - Векторы: Stored (в базе), Reflected (в ответе на запрос), DOM‑based (в браузере). - Кодовые приёмы: - Всегда контекстно‑экранируйте вывод: HTML‑контекст, атрибуты, JS‑литералы, CSS, URL — разный способ кодирования. Пример (псевдокод): `output = escapeHTML(userInput)` и вставка как текст, а не в raw HTML. - Используйте шаблонизаторы с автоэкранированием (React, Handlebars, Twig) и избегайте конструкций, дающих raw HTML (например, `innerHTML`, `dangerouslySetInnerHTML`). - Для допуска "разметки" применяйте белый список тегов/атрибутов и проверенные санитайзеры (например, DOMPurify) для браузера или HTML‑sanitizer на сервере. - Помечайте cookies как `HttpOnly` и `Secure`, чтобы JS не мог их прочитать. - Архитектурные решения: - Внедрите Content Security Policy (CSP) с явными источниками и nonce: `Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...';`. - Минимизируйте использование пользовательского HTML; при необходимости — храните только безопасный формат (Markdown → серверный рендер). - Регулярный статический анализ и тесты (SAST, DAST), ревью шаблонов. CSRF (Cross‑Site Request Forgery) - Что это: злоумышленник заставляет браузер аутентифицированного пользователя выполнить нежелательное запрос‑действие (cookies браузера отправляются автоматически). - Кодовые приёмы: - Anti‑CSRF токены: генерируйте криптографически стойкий токен, привязывайте к сессии и проверяйте его для всех state‑changing запросов (POST/PUT/DELETE). Пример схемы: вставить `` и сверять на сервере. - Double submit cookie: выставить cookie с токеном и требовать совпадение с полем формы/заголовком. - Для SPA/REST API используйте авторизацию через заголовки (Bearer токен) — браузер не отправляет такие заголовки автоматически, поэтому CSRF не работает. - Проверяйте заголовки `Origin` или `Referer` для POST‑запросов (особенно если приложение браузер‑ориентировано). - Никогда не используйте GET для мутаций. - Архитектурные решения: - Устанавливайте cookies с `SameSite=Lax`/`Strict` (например, `Set-Cookie: session=...; SameSite=Strict; Secure; HttpOnly`). - Разделяйте API и браузерную аутентификацию (cookie для UI, token для API). - Включите CORS политику строго по origin для API. SSRF (Server‑Side Request Forgery) - Что это: злоумышленник заставляет сервер выполнять HTTP/DNS/прочие запросы в произвольные адреса (включая внутренние сети, метаданные облака и т.п.). - Кодовые приёмы: - Входная валидация: разрешайте только допустимые схемы (`http`, `https`) и применяйте белый список хостов/доменов. Запрещайте `file:`, `gopher:`, `ftp:` и т.п. - Нормализация URL и валидация IP: разрешение имени в IP и проверка, что IP не попадает в приватные/loopback/специальные диапазоны, например: ‘10.0.0.0/8‘,‘172.16.0.0/12‘,‘192.168.0.0/16‘,‘127.0.0.0/8‘,‘::1‘,‘fc00::/7‘`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `::1`, `fc00::/7`‘10.0.0.0/8‘,‘172.16.0.0/12‘,‘192.168.0.0/16‘,‘127.0.0.0/8‘,‘::1‘,‘fc00::/7‘. - Отключайте/ограничивайте редиректы и глубину редиректов; лимитируйте время ожидания и размер тела ответа. - Используйте предварительные HEAD‑запросы и проверку Content‑Type перед загрузкой больших данных. - Пример проверки (псевдокод): - parse URL → убедиться в схеме `http/https` → resolve hostname → получить список IP → для каждого IP проверить, что он не в приватных диапазонах → только затем выполнять fetch. - Архитектурные решения: - Ограничьте исходящий трафик сервера через egress‑firewall/ACL, разрешая только внешние IP или прокси. - Выполняйте внешние fetch‑запросы через безопасный внешний сервис/прокси в отдельной сети (isolated fetcher) без доступа к internal/vpc сети. - Защитите облачные метаданные (IMDS) — требуйте MFA/токены (IMDS v2), сегментируйте сеть. - Мониторинг и алерты на необычные исходящие запросы, rate limiting для обращений к функции загрузки URL. Общие рекомендации - Принцип наименьших привилегий: минимизируйте права сервисов и сетевые возможности. - Логирование и мониторинг: записывайте и анализируйте неуспешные проверки CSRF/SSRF, подозрительные вводы (XSS). - Тестирование: SAST/DAST, фуззинг входных данных, ревью безопасности. - Обновления зависимостей и использование проверенных библиотек (санитайзеры, шаблонизаторы). Если нужно — могу прислать конкретные короткие реализации (Node/Python) для: контекстного экранирования, генерации/проверки CSRF‑токена и проверки SSRF (resolve+CIDR‑check).
- Что это: внедрение и исполнение злого JavaScript в браузере жертвы через уязвимый вывод данных.
- Векторы: Stored (в базе), Reflected (в ответе на запрос), DOM‑based (в браузере).
- Кодовые приёмы:
- Всегда контекстно‑экранируйте вывод: HTML‑контекст, атрибуты, JS‑литералы, CSS, URL — разный способ кодирования. Пример (псевдокод): `output = escapeHTML(userInput)` и вставка как текст, а не в raw HTML.
- Используйте шаблонизаторы с автоэкранированием (React, Handlebars, Twig) и избегайте конструкций, дающих raw HTML (например, `innerHTML`, `dangerouslySetInnerHTML`).
- Для допуска "разметки" применяйте белый список тегов/атрибутов и проверенные санитайзеры (например, DOMPurify) для браузера или HTML‑sanitizer на сервере.
- Помечайте cookies как `HttpOnly` и `Secure`, чтобы JS не мог их прочитать.
- Архитектурные решения:
- Внедрите Content Security Policy (CSP) с явными источниками и nonce: `Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...';`.
- Минимизируйте использование пользовательского HTML; при необходимости — храните только безопасный формат (Markdown → серверный рендер).
- Регулярный статический анализ и тесты (SAST, DAST), ревью шаблонов.
CSRF (Cross‑Site Request Forgery)
- Что это: злоумышленник заставляет браузер аутентифицированного пользователя выполнить нежелательное запрос‑действие (cookies браузера отправляются автоматически).
- Кодовые приёмы:
- Anti‑CSRF токены: генерируйте криптографически стойкий токен, привязывайте к сессии и проверяйте его для всех state‑changing запросов (POST/PUT/DELETE). Пример схемы: вставить `` и сверять на сервере.
- Double submit cookie: выставить cookie с токеном и требовать совпадение с полем формы/заголовком.
- Для SPA/REST API используйте авторизацию через заголовки (Bearer токен) — браузер не отправляет такие заголовки автоматически, поэтому CSRF не работает.
- Проверяйте заголовки `Origin` или `Referer` для POST‑запросов (особенно если приложение браузер‑ориентировано).
- Никогда не используйте GET для мутаций.
- Архитектурные решения:
- Устанавливайте cookies с `SameSite=Lax`/`Strict` (например, `Set-Cookie: session=...; SameSite=Strict; Secure; HttpOnly`).
- Разделяйте API и браузерную аутентификацию (cookie для UI, token для API).
- Включите CORS политику строго по origin для API.
SSRF (Server‑Side Request Forgery)
- Что это: злоумышленник заставляет сервер выполнять HTTP/DNS/прочие запросы в произвольные адреса (включая внутренние сети, метаданные облака и т.п.).
- Кодовые приёмы:
- Входная валидация: разрешайте только допустимые схемы (`http`, `https`) и применяйте белый список хостов/доменов. Запрещайте `file:`, `gopher:`, `ftp:` и т.п.
- Нормализация URL и валидация IP: разрешение имени в IP и проверка, что IP не попадает в приватные/loopback/специальные диапазоны, например: ‘10.0.0.0/8‘,‘172.16.0.0/12‘,‘192.168.0.0/16‘,‘127.0.0.0/8‘,‘::1‘,‘fc00::/7‘`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `::1`, `fc00::/7`‘10.0.0.0/8‘,‘172.16.0.0/12‘,‘192.168.0.0/16‘,‘127.0.0.0/8‘,‘::1‘,‘fc00::/7‘.
- Отключайте/ограничивайте редиректы и глубину редиректов; лимитируйте время ожидания и размер тела ответа.
- Используйте предварительные HEAD‑запросы и проверку Content‑Type перед загрузкой больших данных.
- Пример проверки (псевдокод):
- parse URL → убедиться в схеме `http/https` → resolve hostname → получить список IP → для каждого IP проверить, что он не в приватных диапазонах → только затем выполнять fetch.
- Архитектурные решения:
- Ограничьте исходящий трафик сервера через egress‑firewall/ACL, разрешая только внешние IP или прокси.
- Выполняйте внешние fetch‑запросы через безопасный внешний сервис/прокси в отдельной сети (isolated fetcher) без доступа к internal/vpc сети.
- Защитите облачные метаданные (IMDS) — требуйте MFA/токены (IMDS v2), сегментируйте сеть.
- Мониторинг и алерты на необычные исходящие запросы, rate limiting для обращений к функции загрузки URL.
Общие рекомендации
- Принцип наименьших привилегий: минимизируйте права сервисов и сетевые возможности.
- Логирование и мониторинг: записывайте и анализируйте неуспешные проверки CSRF/SSRF, подозрительные вводы (XSS).
- Тестирование: SAST/DAST, фуззинг входных данных, ревью безопасности.
- Обновления зависимостей и использование проверенных библиотек (санитайзеры, шаблонизаторы).
Если нужно — могу прислать конкретные короткие реализации (Node/Python) для: контекстного экранирования, генерации/проверки CSRF‑токена и проверки SSRF (resolve+CIDR‑check).