Рассмотрите сценарий XSS в одностраничном приложении на React: какие источники данных и приёмы рендеринга создают риск, и как защититься на уровне кода и конфигурации?

17 Ноя в 06:52
3 +1
0
Ответы
1
Источники риска
- Входные данные от пользователя: формы, комментарии, поля профиля, upload (особенно SVG/HTML).
- URL (path, query, fragment/hash) — при парсинге и вставке в DOM или в state.
- Хранение в браузере: localStorage/sessionStorage/indexedDB — данные считаются небезопасными при рендеринге.
- Серверный HTML/SSR: если сервер отдаёт неэкранированный HTML или вставки в шаблоны.
- Внешние каналы: postMessage, WebSocket, файлы, third‑party виджеты/скрипты.
- Библиотеки/зависимости с уязвимостями.
- Непосредственные приёмы рендеринга: присваивание innerHTML/insertAdjacentHTML, использование React: , прямые DOM‑манипуляции через refs, eval/new Function, вставка «javascript:» в href/src, вставка inline‑стилей с пользовательскими данными.
Как защититься — код
- Используйте JSX/выражения (React экранирует значения по умолчанию): {userText} вместо innerHTML.
- Полностью избегайте dangerouslySetInnerHTML; если невозможно — обязательно санитизируйте:
- DOMPurify (рекомендуется) с строгой конфигурацией: запретить event‑атрибуты, script, style и т.п.
- Пример:
- sanitize = DOMPurify.sanitize(dirtyHtml);
- - Валидируйте и нормализуйте URL перед вставкой в href/src (запретить схемы javascript:, data: и т.п.):
- Пример проверки: использовать new URL(..., origin) и whitelist протоколов (http, https, mailto, tel).
- Для атрибутов и стилей: не вставлять пользовательские строки в атрибуты, использовать безопасные API (element.textContent, element.setAttribute только с проверенными значениями).
- Не использовать eval, new Function, setTimeout/ setInterval с строкой.
- Для SVG/файлов — удалить скрипты и потенциально опасные атрибуты при загрузке.
- Обрабатывать данные из localStorage/sessionStorage/IndexedDB как недоверенные — санитизировать перед отображением.
- Ограничивать/фильтровать содержимое, разрешая только нужные теги/атрибуты (white‑list), а не блокировать known bad (черный список ненадёжен).
Как защититься — конфигурация/заголовки
- Content‑Security‑Policy:
- script‑src 'self' 'nonce-...'/hashes; object‑src 'none'; base‑uri 'none'; default‑src 'none' или минимально необходимые источники.
- Рассмотреть 'strict-dynamic' и хэши/nonce для безопасной загрузки динамических скриптов.
- Включить require‑trusted‑types‑for 'script' + внедрить Trusted Types политики для контроля присваиваний innerHTML.
- Trusted Types: запретить присвоение innerHTML без политики; в SPA создать политику, которая принимает только результат валидной санитации.
- X-Content-Type-Options: nosniff; Strict-Transport-Security; Referrer-Policy; Permissions-Policy; установить Secure, HttpOnly, SameSite для куки.
- Subresource Integrity (SRI) для внешних скриптов, минимизировать сторонние скрипты и виджеты.
Процессы и проверка
- Статический анализ/ESLint правила (например запрет опасного innerHTML / eslint-plugin-react/no-dangerous-html).
- Сканирование зависимостей (Snyk, npm audit), тестирование на XSS (автоматические тесты, CSP report‑only).
- Code review и security review для участков, где рендерится HTML.
- Пентесты/динамическое тестирование (DAST) на продакшн/стейдж.
Краткие практические правила
- Всегда считать внешние/пользовательские данные небезопасными.
- По возможности рендерить как текст; только при необходимости сертифицированная санитизация + Trusted Types + CSP.
- Валидировать/нормализовать URL, не использовать inline‑scripts/inline‑styles без nonce/hashes.
- Минимизировать и контролировать сторонние скрипты.
Если нужно — могу привести короткие код‑примеры безопасной санитизации (DOMPurify) и функции проверки URL.
17 Ноя в 07:00
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Прямой эфир