XSS на практике

Сначала авторизация: это урок для защитника

Всё, что ниже, предполагает подписанный контракт с явно очерченным scope — лабораторию, CTF, программу bug-bounty с целью из списка, или собственное приложение. Внедрение скрипта в живое приложение, которым ты не владеешь, даже «просто чтобы доказать», способно скомпрометировать сессии реальных пользователей и переходит правовую черту вне зависимости от намерений. На настоящей оценке тестировщики используют безобидный, недеструктивный маркер (диалоговое окно, обращение к подконтрольному им логирующему серверу), чтобы доказать наличие точки внедрения, — но никогда код, который реально крадёт данные у настоящих пользователей. Мы изучаем механизм, чтобы защитник увидел, где именно его фреймворк отдаёт данные браузеру как код, и закрыл эту дверь. Читай это как blue-teamer, узнающий, что атакующий уже знает о твоём пути рендеринга.

Межсайтовый скриптинг (XSS) относится к категории OWASP Injection — то же семейство, что и SQL-инъекция, — и корневая причина та же: недоверенные данные интерпретируются как код неким интерпретатором. У SQLi интерпретатор — база данных; у XSS — браузер. Одно предложение, описывающее любой баг XSS: приложение взяло данные, подконтрольные атакующему, и поместило их в страницу в контексте, где браузер их исполняет. Всё остальное — детали о том, какая страница и какой контекст.

Три формы

XSS классифицируют по тому, где хранится вредоносная нагрузка и как она доходит до браузера жертвы. У форм общий итог, но резко различаются радиус поражения и место, где их чинят.

Отражённая XSS — самая простая: сервер берёт значение из запроса — поисковый запрос, параметр ошибки — и пишет его прямо обратно в HTML-ответ без кодирования. Нагрузка атакующего нигде не хранится; она живёт в URL, который надо доставить, поэтому каждой жертве нужна подготовленная ссылка (фишинг, пост, реклама). Одна ссылка — одна жертва, но рассылается она массово без труда.

Хранимая XSS — опасная. Нагрузка записывается в твой слой хранения — комментарий, имя пользователя, тело тикета поддержки — и затем отдаётся всем, кто просматривает страницу, без всякой ссылки. Именно это делает хранимую XSS классом «червей»: нагрузка может исполняться в сессии каждого зрителя и переотправлять саму себя — ровно так червь Samy в 2005 поразил миллион профилей MySpace меньше чем за сутки. Угол привилегированного зрителя — добивающий: данные, записанные малопривилегированным атакующим, исполняются в браузере администратора, открывшего очередь модерации.

DOM-based XSS — та, что серверные защиты пропускают полностью. Здесь уязвимый код — клиентский JavaScript: страница читает подконтрольный атакующему ввод из источника (обычно location.hash, location.search, document.referrer или данные postMessage) и передаёт его в опасный sink, превращающий строки в живой DOM или код (element.innerHTML, document.write, eval, старый HTML-путь jQuery $(...)). Вредоносная строка может сидеть во фрагменте URL после #, который браузеры никогда не отправляют на сервер, — поэтому серверные логи, твой WAF и серверное кодирование её даже не видят. Уязвимость — это небезопасный поток источник→sink в браузере, и чинить её надо именно там.

Что атакующий реально получает

Как только JavaScript атакующего исполняется внутри твоего origin, он работает со всеми полномочиями, которые браузер жертвы даёт твоему сайту. Эту часть недооценивают: XSS — это не «всплывашка», это произвольное исполнение кода в контексте безопасности твоего приложения. Конкретно: скрипт может прочитать любой cookie без флага HttpOnly и любой токен, который твой SPA держит в localStorage, и слить его на сервер атакующего. Он может вызывать твой собственный API от лица жертвы — сменить ей email, перевести деньги, опубликовать контент — потому что запрос несёт сессию жертвы автоматически и исходит с твоей же страницы, проходя мимо защит same-origin и CSRF. Он может логировать клавиши, переписать DOM ради фишинга учётных данных или сделать pivot: сессия администратора, перехваченная хранимой XSS в инструменте поддержки, часто — прямой путь к целому тенанту. Сессионный cookie — главный приз именно потому, что его кража позволяет атакующему полностью пропустить аутентификацию.

Лекарство: кодируй по контексту, затем CSP как страховка

Инстинкт «санитизировать ввод» — неверный первичный контроль, и зрелые инженеры знают почему: значение опасно не когда оно сохранено, а когда оно отрендерено в конкретный контекст. Одна и та же строка безобидна внутри текстового узла HTML, выламывается из атрибута HTML и катастрофична внутри блока <script> или URL javascript:. Поэтому каноническая защита — это выходное кодирование, выбранное под контекст, в который ты вставляешь: HTML-entity-кодирование для текста элемента, атрибутное кодирование (с кавычками) для атрибутов, JavaScript-кодирование для скриптовых контекстов, URL-кодирование для параметров URL. Современные фреймворки делают большую часть этого за тебя: React, Angular и Vue автоматически экранируют интерполируемые значения — поэтому XSS в таких приложениях кучкуется вокруг люков-обходов (dangerouslySetInnerHTML, [innerHTML], v-html) и вокруг DOM-sink, которые фреймворк не опосредует. Конкретно для DOM XSS лекарство — избегать строка-в-DOM sink (textContent вместо innerHTML) и, в идеале, включить Trusted Types, чтобы браузер отказывал сырым строкам у опасных sink.

Затем приходит слой, рассчитанный на то, что одну ты пропустишь, — Content-Security-Policy. Строгий CSP, запрещающий inline-скрипты и разрешающий скрипты только из источников, которые ты назвал (через nonce на запрос или хеши), означает, что даже когда внедрение приземлится, браузер откажется исполнять <script> атакующего — политика его не авторизовала. CSP — это defence-in-depth, а не замена кодированию: он не чинит баг, он сдерживает радиус поражения того бага, что ты не поймал. Зрелая позиция — и то, и другое: кодируй корректно у каждого sink, чтобы внедрения не образовывались, и поставляй CSP на основе nonce, чтобы то, что ты пропустишь, всё равно не исполнилось.