xss атака

XSS атака (Cross-Site Scripting, межсайтовый скриптинг) — тип уязвимости веб-приложений, позволяющий злоумышленнику внедрить вредоносный JavaScript-код на страницу которую видят другие пользователи. Браузер жертвы исполняет этот код в контексте доверенного сайта, что открывает возможность кражи куки, перехвата сессий, перенаправления на фишинговые страницы и изменения содержимого сайта. XSS стабильно входит в OWASP Top 10 как одна из наиболее распространённых веб-уязвимостей.

Типы XSS атак

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

Вредоносный код содержится в URL и отражается сервером обратно в ответе. Пользователь переходит по специально сформированной ссылке, сервер включает параметр запроса в HTML без экранирования, и браузер выполняет скрипт. Reflected XSS не сохраняется на сервере и срабатывает только при переходе по заражённому URL — злоумышленник должен заставить жертву перейти по ссылке.

Stored XSS (хранимый)

Вредоносный код сохраняется в базе данных и показывается всем пользователям при загрузке страницы. Наиболее опасный тип: жертва не должна переходить ни по каким ссылкам. Комментарии, имена пользователей, описания товаров — типичные векторы внедрения. Один заражённый пост в форуме атакует тысячи посетителей, пока администратор не удалит вредоносный контент.

DOM-based XSS

Вредоносный код выполняется на стороне клиента через манипуляцию DOM без участия сервера. JavaScript читает данные из location.hash, location.search или других источников и записывает их в DOM через innerHTML, document.write или аналогичные методы. Сервер не участвует в атаке, поэтому серверные средства защиты не помогают.

Последствия XSS

Успешная XSS-атака даёт злоумышленнику широкие возможности: кража session cookies и токенов аутентификации, keylogging — перехват нажатий клавиш пользователя, изменение содержимого страницы (подмена форм для сбора данных карт), перенаправление на фишинговые сайты, распространение червей через социальные сети (MySpace Worm, 2005), использование браузера жертвы для атак на другие ресурсы через BeEF framework.

Защита от XSS

Контекстное экранирование вывода

Главная защита — экранировать все данные перед вставкой в HTML. HTML-экранирование заменяет символы меньше/больше, кавычки и амперсанд на HTML-сущности. Контекст имеет значение: данные в атрибуте тега, в JavaScript-строке или в URL требуют разного экранирования. Библиотека DOMPurify позволяет безопасно отображать HTML-контент от пользователей удаляя опасные теги и атрибуты.

Content Security Policy (CSP)

CSP — HTTP-заголовок ограничивающий источники из которых браузер может загружать и исполнять скрипты. Директива script-src self запрещает выполнение инлайн-скриптов и скриптов с внешних доменов. CSP — эффективный второй уровень защиты, значительно ограничивающий последствия XSS даже при наличии уязвимости.

HttpOnly и Secure куки

Флаг HttpOnly делает куки недоступными для JavaScript. Даже при успешной XSS-атаке злоумышленник не сможет похитить session cookie. Флаг Secure гарантирует передачу куки только по HTTPS. Совместное использование обоих флагов существенно снижает ущерб от XSS-атак на аутентификацию.

Современные фреймворки

React, Vue, Angular экранируют данные по умолчанию при вставке в DOM. Опасна только явная работа с dangerouslySetInnerHTML (React) или v-html (Vue) — эти механизмы использовать только с доверенными данными. Для пользовательского HTML-контента всегда применяйте библиотеки санитизации.

Частые вопросы

  • Чем XSS отличается от CSRF?

    XSS — внедрение вредоносного кода который выполняется в браузере жертвы от имени доверенного сайта. CSRF — принуждение браузера жертвы отправить запрос к сайту на котором пользователь аутентифицирован. XSS использует доверие пользователя к сайту, CSRF — доверие сайта к браузеру пользователя.

  • Защищает ли экранирование HTML от всех типов XSS?

    Нет. HTML-экранирование защищает от вставки тегов в HTML-контент, но не от DOM-based XSS где данные обрабатываются в JavaScript без участия сервера. Нужен комплексный подход: экранирование с учётом контекста, CSP-заголовки и безопасная работа с DOM API.

  • Может ли React или Vue полностью защитить от XSS?

    Они значительно снижают риск автоматически экранируя данные в шаблонах. Но уязвимость остаётся при использовании dangerouslySetInnerHTML (React) или v-html (Vue), при работе с URL-параметрами в href-атрибутах и при прямых манипуляциях DOM через refs.

Не хватает деталей?

Напишите, что уточнить по теме «xss атака» — это помогает улучшать материал и подсказывает, какие термины добавить дальше. Email необязателен: укажите, если хотите ответ только для вас (мы не шлём рассылки).

Поделиться