Кратко — что такое XSS и как с ним работать, с примером в PHP и практическими рекомендациями.
Что такое XSS
- XSS (Cross‑Site Scripting) — внедрение и исполнение вредоносного JavaScript в браузере жертвы через данные, которые приложение некорректно выводит в страницу. Виды: отражённый, хранимый, DOM‑based.
- Главная ошибка: экранирование/санитизация данных выполняется неправильно или не там, где нужно (чаще — при вводе вместо вывода, либо вообще отсутствует).
Уязвимый шаблон в PHP (пример)
```
<?php
// /search.php?query=alert(1) $query = $_GET['query'];
?>Результаты поиска для: ещё var q = "";
// использование q в JS
```
Проблема: пользовательская строка вставляется в HTML, в атрибут URL и в JS без экранирования → XSS везде.
Как правильно — принцип: никогда не доверяйте входу; экранируйте при выводе в конкретный контекст (output encoding). Не «чистите на входе» вместо экранирования.
Правильные исправления (по контекстам)
- В HTML‑контексте (текст между тегами) используйте:
```
echo htmlspecialchars($query, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
```
- В атрибуте (href, value, title) — те же htmlspecialchars; дополнительно валидируйте URL и/или применяйте rawurlencode для составной части:
```
... ```
- В JS‑контексте — никогда не вставляйте необработанные строки в литералы JS. Используйте json_encode для безопасной сериализации:
```
var q = ;
```
или храните данные в data-атрибуте (экранируя через htmlspecialchars) и читайте через DOM API.
- В URL (например, в параметрах) — rawurlencode.
- Для HTML фрагментов, которые действительно должны содержать разрешённый HTML — применяйте белый список тегов/атрибутов на сервере (например, HTMLPurifier) и затем точно указывайте контекст вывода.
Дополнительные рекомендации
- Никогда не отключайте экранирование глобально. Шаблонизаторы с авто-экранировкой (Twig, Blade) помогают, но разработчик должен понимать контексты.
- Не делайте «фильтрацию» на входе в попытке удалить теги; экранирование при выводе — основа.
- Устанавливайте заголовки: Content-Type с правильной кодировкой (например, text/html; charset=UTF-8), HttpOnly и Secure для сессионных cookie.
- Внимание на DOM‑XSS: проверяйте операции с location, document.write, innerHTML, eval в клиентском JS.
Content Security Policy (CSP) — когда и как применять
- CSP — дополнительный уровень защиты, ограничивает откуда можно загружать и исполнять скрипты/стили/ресурсы; полезна для смягчения последствий XSS и управления сторонними ресурсами.
- Но CSP не заменяет экранирование: CSP уменьшает риск, что внедрённый скрипт выполнит полезную работу (если политика строгая), но не предотвращает возможность инъекции и не защищает от всех видов DOM‑XSS (например, если внедрённый код попадает в уже разрешённый inline‑скрипт).
- Практическое применение:
- Используйте «script-src 'self' 'nonce-...';» и генерируйте уникальный nonce для каждой страницы для разрешения только тех inline‑скриптов, которым вы доверяете.
- Предпочтительнее: избегать inline‑скриптов и использовать внешние файлы со строгим источником (script-src 'self').
- Запретите object/embed (object-src 'none'), ограничьте frame‑ancestors, применяйте upgrade-insecure-requests при необходимости.
- Пример заголовка CSP (строгое, с nonce):
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';
(Вместо report-uri используйте report-to для современных браузеров.)
- Nonce workflow: генерируйте крипто‑стойкий nonce на сервере для каждой страницы, вставляйте его в заголовок CSP и в атрибут script nonce в доверенных inline‑скриптах. Это предотвращает выполнение внедрённых inline‑скриптов без допустимого nonce.
Когда применять экранирование, а когда CSP
- Обязательно применять экранирование при любом выводе данных — всегда. Это первичная защита.
- CSP — дополнительная, «контролирующая» мера: внедрите CSP чтобы снизить последствия возможных пробелов (например, сторонние библиотеки, старый код), а также чтобы запретить внешние ресурсы.
- Итого: экранирование = обязательное средство; CSP = сильное дополнение (особенно полезно при поэтапном улучшении безопасности и для защиты от эксплуатаций, где экранирование может пропуститься).
Короткая чек‑лист‑реализация
- Всегда экранируйте при выводе: htmlspecialchars для HTML/атрибутов, rawurlencode для URL, json_encode для JS.
- Используйте шаблонизатор с автоэкранированием.
- Проводите аудит клиентского JS (document.write, innerHTML, eval).
- Включите строгий CSP с по возможности отсутствием inline и с nonce/hashes для доверенных скриптов.
- Устанавливайте безопасные cookie‑флаги и корректный Content-Type/charset.
Если хотите, могу быстро показать исправленную версию приведённого примера с nonce‑CSP и правильным экранированием.