Введение
Если у вас есть сайт на CMS или форум, то XSS и CSRF — это одни из самых распространённых и при этом опасных видов атак, которые могут серьёзно навредить вам и вашим пользователям. Бывают ситуации, когда сайт вроде бы простой, но одна уязвимость с такой страницы — и вся база слилась, админка взломана, доверие подорвано. Звучит страшно, но в реальности защититься не так сложно, как кажется. Главное — понять, как эти атаки работают и какие меры можно принять, чтобы их предотвратить. Давайте разбираться, что это такое и как с этим бороться на практике.

Что такое XSS и CSRF?

XSS — это Cross-Site Scripting. Проще говоря, злоумышленник внедряет вредоносный скрипт в ваш сайт с помощью уязвимого поля ввода. Например, в комментариях к статье или в форме обратной связи. Этот скрипт потом запускается в браузерах других пользователей, которые заходят на вашу страницу. Итог — могут украсть cookie, сессионные данные или даже полностью подменить содержимое страницы. Очень часто жертвой становятся обычные пользователи, а не администраторы, но последствия могут быть хоть для всех, хоть для вас лично.

CSRF — Cross-Site Request Forgery — это когда злоумышленник заставляет пользователя выполнить какое-то действие на сайте, где он уже авторизован, без его ведома. Постучать в админку с чужого браузера не выйдет, а вот заставить пользователя поменять пароль, отправить форму или что-то удалить — вполне. Обычно это достигается размещением скрытых форм или автоматическим выполнением скриптов на стороннем ресурсе, где пользователь просто оказался залогинен. Особенно под ударом сайты с чувствительными настройками и финансовыми операциями.

Где чаще всего встречаются эти уязвимости

XSS:
- Поля комментариев, где можно писать что угодно.
- Формы обратной связи или регистрации — если ввод не фильтруется.
- Личные данные и профили — например, возможности обновления описания или статуса.
- Посты на форумах и блогах.

CSRF:
- Действия, которые меняют что-то в аккаунте: смена пароля, почты, параметров профиля.
- Создание или удаление записей, сообщений, товаров и прочих сущностей.
- Операции в админках, которые управляют сайтом.
- Оплата или финансовые переводы (если есть).

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

1. XSS на примере комментария. Представьте, что вы разрешаете в комментариях медиа и ссылки, но не фильтруете символы <, > или кавычки. Злоумышленник вставляет кусок JS-кода через тег <script>. При загрузке страницы этот скрипт выполняется у каждого, кто читает комментарии — может отправлять их cookie на внешний сервер.

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

Основные меры защиты

Для XSS:
- Всегда экранируйте пользовательский ввод, который выводите на страницу (заменяйте < на &lt; и так далее).
- Используйте Content Security Policy (CSP) — политика, которая ограничивает, какие скрипты могут выполняться на сайте.
- Не позволяйте вставлять небезопасные HTML-теги и атрибуты, если есть возможность фильтровать.
- Применяйте специальные библиотеки или методы для безопасного вывода контента (например, htmlspecialchars в PHP).

Для CSRF:
- Добавляйте CSRF-токены в каждую форму, которая меняет данные. Это случайная строка, проверяемая на сервере.
- Настраивайте проверку Referer и Origin-заголовков — но не полагайтесь только на них.
- Используйте методы аутентификации с защитой от сессий вне браузера (например, куки с HttpOnly и Secure).
- Ограничивайте время жизни сессии.

Чек-лист для проверки безопасности сайта

1. Все пользовательские данные проходят проверку и экранирование перед выводом.
2. На каждая форма с действиями есть уникальный CSRF-токен.
3. Используется Content Security Policy.
4. Нет прямого вывода данных из БД без очистки.
5. Проверены заголовки запроса (Referer, Origin).
6. Сессии настроены с флагами безопасности для куки.
7. Админка защищена отдельной авторизацией с более жёсткими правилами.
8. Обновляете CMS и плагины — чтобы не быть уязвимыми из-за старого кода.
9. Регулярно делаете аудит безопасности.

Типичные ошибки, которые я встречал

- Просто запрещают все теги в комментариях, но при этом забывают проверять атрибуты, где тоже можно впихнуть JS.
- Надеются, что белый список тегов решит проблему, но он не полноценная защита.
- Не используют CSRF-токены именно для POST-запросов и боятся внедрять их из-за “усложнения формы”.
- Пытаются проверить CSRF по Referer, а этот заголовок легко спойфить или просто не приходит у некоторых клиентов.
- Используют устаревшие версии CMS, где эти уязвимости давно известны и есть готовые патчи.
- Не проводят тесты и не пользуются автоматическими сканерами уязвимостей.

FAQ

В: Можно ли полностью избежать XSS, просто запрещая все пользовательские скрипты?
О: Теоретически да, но часто хочется разрешить хоть какую-то разметку или ссылки. В таком случае лучше ставить фильтры и использовать проверенные библиотеки для санитайза. Главное — не выводить “голые” данные без обработки.

В: Что делать, если использую CMS, где нет поддержки CSRF-токенов?
О: Вариантов несколько: либо вручную дописывать поддержку CSRF в темы или плагины, либо сменить CMS на более современную и безопасную. Использовать сторонние модули проверки запроса почти всегда можно.

В: Есть ли смысл использовать только проверку Referer для CSRF?
О: Нет. Referer можно подделать или он просто может не дойти. Это дополнительный уровень, но базовая защита — именно уникальные токены в формах.

В: Насколько надежен Content Security Policy?
О: CSP помогает значительно снизить риски XSS, но нельзя слепо на него полагаться. Важно параллельно фильтровать ввод и правильно работать с выводом.

В: Как проверить, есть ли на моём сайте XSS или CSRF?
О: Можно пользоваться сканерами безопасности, которые умеют имитировать атаки. Ручная проверка — тестировать всё, где есть пользовательский ввод и формы. Также полезно просить людей из ИБ-сообщества протестить ваш сайт.

В итоге
Защита от XSS и CSRF — это не какой-то магический процесс, а обычная практика продуманной разработки и настройки сайта. Если вы разбираетесь в том, где уязвимости могут появиться, и последовательно закрываете их, сайт становится намного безопаснее. Если что — задавайте вопросы, делитесь своими историями и советами!