Книга: «Все об уязвимости XSS». Глава 1: Введение — Добро пожаловать в мир XSS 🎯 • Что такое XSS и почему это твой новый любимый вектор атаки
Cross-Site Scripting (XSS) — это уязвимость, которая позволяет злоумышленнику внедрить произвольный JavaScript-код в веб-страницу, просматриваемую другими пользователями. По сути, ты заставляешь чужой браузер выполнять твой код в контексте доверенного сайта. И да, это настолько мощно, насколько звучит.
Представь: ты находишь точку входа (input field, URL-параметр, любое место, где сайт принимает данные), вставляешь туда что-то вроде `<script>alert(document.cookie)</script>`, и бум — браузер жертвы послушно выполняет твой код. Теперь у тебя доступ к cookie, session tokens, можешь перехватывать нажатия клавиш, редиректить пользователя на фишинговую страницу или вообще полностью контролировать его сессию.
Почему XSS — это король веб-уязвимостей
XSS держится в топе OWASP уже больше двадцати лет. Не потому что разработчики тупые (хотя бывает), а потому что современный веб — это сложная экосистема фреймворков, библиотек и легаси-кода, где одна забытая проверка входных данных превращается в дыру размером с ворота.
Вот почему XSS — твой лучший друг в мире пентеста:
Распространённость. XSS встречается везде: от корпоративных порталов до блогов на WordPress. По статистике bug bounty платформ, XSS составляет 20-30% всех найденных уязвимостей. Это значит, что шансы найти её в следующем приложении, которое ты тестируешь, чертовски высоки.
Низкий порог входа. Не нужно быть гением криптографии или знать ассемблер. Базовый XSS можно найти, просто засунув `<script>alert(1)</script>` в каждое поле формы. Конечно, обход современных фильтров — это уже искусство, но начать легко.
Высокая ценность. На bug bounty платформах типа HackerOne или Bugcrowd за XSS платят от нескольких сотен до десятков тысяч долларов, в зависимости от severity. Stored XSS в критичной функциональности? Это может быть твой джекпот на $10k+.
Гибкость эксплуатации. XSS — это не просто “показать alert”. Это полноценный векторы для session hijacking, credential theft, распространения вредоносного ПО, социальной инженерии, и даже для цепочек атак на внутреннюю инфраструктуру через SSRF.
Анатомия простейшей атаки
Давай разберём классический сценарий. Есть сайт с поиском. Пользователь вводит запрос, сайт показывает результаты и выводит: “Результаты по запросу: твой_запрос”. Если разработчик не проверяет и не экранирует ввод, ты можешь сделать так:
https://vulnerable-site.com/search?q=<script>alert('XSS')</script>Браузер жертвы откроет эту ссылку, сервер вернёт HTML, где твой запрос вставлен напрямую в страницу:
<p>Результаты по запросу: <script>alert('XSS')</script></p>JavaScript выполнится. Это Reflected XSS — самый простой тип. Но если этот же поисковый запрос сохраняется в базе данных и показывается всем посетителям (например, в разделе “популярные запросы”), то это уже Stored XSS — гораздо опаснее, потому что твой payload срабатывает автоматически для каждого, кто зайдёт на страницу.
Почему это работает до сих пор
Казалось бы, в 2025 году все должны были научиться экранировать ввод. Но нет. Причин несколько:
Легаси-код. Многие сайты работают на коде, написанном 10-15 лет назад, когда про безопасность думали в последнюю очередь. Рефакторинг старых систем — дорого и рискованно, поэтому уязвимости живут годами.
Сложность современного стека. React, Angular, Vue — эти фреймворки вроде бы защищают от XSS по умолчанию, но стоит разработчику использовать `dangerouslySetInnerHTML` или неправильно обработать пользовательский ввод в URL, и дыра готова.
Человеческий фактор. Даже опытные разработчики делают ошибки. Забыл проверить один параметр, не учёл edge case с энкодингом, использовал устаревшую библиотеку — и привет, XSS.
Новые векторы. Технологии развиваются, появляются новые API, новые контексты выполнения кода. То, что вчера было безопасно, сегодня может оказаться уязвимым. Mutation XSS (mXSS), DOM Clobbering, XS-Leaks — это новые грани старой атаки.
Что ты можешь сделать с XSS
Как только ты нашёл XSS, начинается настоящее веселье. Вот что можно сделать:
Украсть cookie и захватить сессию. Самый классический вариант. `document.cookie` отправляется на твой сервер, и ты логинишься под жертвой.
Кейлоггинг. Повесить event listener на `keydown` и отправлять всё, что жертва печатает — пароли, номера карт, личные сообщения.
Фишинг на месте. Подменить форму логина прямо на странице. Пользователь видит знакомый интерфейс и вводит свои данные — прямо тебе в руки.
Редирект на малварь. Перенаправить жертву на сайт с эксплойтом браузера или просто на фейковую страницу обновления Adobe Flash (да, люди до сих пор на это ведутся).
Использовать BeEF. Browser Exploitation Framework превращает браузер жертвы в зомби-машину, которой ты управляешь через веб-интерфейс. Можешь сканировать внутреннюю сеть, красть файлы, делать скриншоты — всё что душе угодно.
Почему админы боятся `<script>alert(1)</script>`
Этот payload стал мемом в комьюнити. Он не делает ничего вредного — просто показывает alert. Но если он сработал, значит, можно выполнить любой JavaScript. А любой JavaScript = полный контроль над браузером пользователя в контексте этого сайта.
Для админа это кошмар. XSS может обойти все защиты на уровне приложения, потому что код выполняется уже после того, как сервер отдал страницу. WAF, rate limiting, IP-блокировки — всё бесполезно, если твой payload уже в DOM’е.
Более того, XSS часто используется как первый шаг в цепочке атак. Нашёл XSS → украл cookie админа → залогинился в админку → нашёл RCE → получил шелл на сервере. Это классический сценарий, и он работает снова и снова.
Твой путь в мире XSS
Эта книга — твой гайд от новичка до профи. Мы пройдём через все типы XSS, научимся обходить фильтры, писать свои эксплойты и автоматизировать поиск. К концу ты будешь видеть XSS там, где другие видят просто форму ввода.
Готов? Погнали дальше, потому что впереди нас ждут Reflected, Stored, DOM-based и куча других видов XSS, каждый со своими фишками и способами эксплуатации.