Почему XSS стал точкой входа для больших языковых моделей
Cross‑Site Scripting (XSS) традиционно считается одной из самых простых, но в то же время самых опасных уязвимостей веб‑приложений. Возможность выполнить произвольный JavaScript в браузере жертвы открывает двери к краже сессий, подмене контента и даже полной компрометации клиентской части. Для LLM (large language models) такие уязвимости представляют идеальный «вектор»: модель умеет генерировать код, подбирая нужные строки скриптов, а также формировать запросы, которые приводят к их исполнению.
С ростом интеграции LLM в CI/CD, чат‑боты и API‑сервисы, атакующие сценарии перестали быть чисто теоретическими. Уже сейчас исследователи подтверждают, что модели способны самостоятельно находить и эксплуатировать XSS‑уязвимости без какого‑либо человеческого вмешательства.
Автономный аудит уязвимостей с помощью GPT‑4
В 2024 году команда из Университета Иллинойса провела масштабный эксперимент: GPT‑4 получил список публично раскрытых CVE и задачу «самостоятельно эксплуатировать каждую уязвимость». Никаких подсказок, только описание из базы.
- Успех: 87 % всех CVE были успешно использованы моделью.
- Сравнение: Ни одна из проверяемых альтернативных моделей и ни один из открытых сканеров уязвимостей не смогли найти ни одной эксплойт‑цепочки.
Неудача GPT‑4 произошла лишь в одном случае — XSS‑уязвимости, где приложение построено на тяжёлой клиентской навигации. Модель не смогла «дойти» до нужного поля ввода, а не из‑за недостатка знаний о XSS. Это указывает на то, что ограничивающим фактором сейчас является способность LLM «обходить» сложные UI, а не её понимание атакующего кода.
Исследователи назвали найденную способность «эмерджентным» (emergent) свойством, подразумевая, что при достаточном объёме данных и вычислительных ресурсах модель приобретает новые навыки без явного обучения под конкретную задачу.
Командные LLM‑агенты и эксплойт нулевых дней
Следующий шаг группы исследователей — построение специализированных агентов. Был сформирован набор из нескольких LLM, каждый из которых отвечал за отдельный тип уязвимости (SQL‑инъекция, XSS, SSRF и т.д.).
Для XSS‑агента был реализован цикл:
- Обход интерфейса – сканирование страниц, поиск интерактивных элементов.
- Идентификация небезопасного вывода – поиск мест, где пользовательские данные выводятся без экранирования.
- Генерация payload – построение JavaScript‑строк, учитывающих контекст (attribute, script‑tag, URL).
- Подтверждение – проверка выполнения кода в изолированной среде.
В результате агенты без какого‑либо описания CVE обнаружили и успешно использовали два нулевых XSS‑эксплойта в популярных open‑source CMS: CVE‑2024‑27757 и CVE‑2024‑34061.
Ключевой момент – агенты самостоятельно «перешли» от статического анализа к динамической проверке, используя браузерные эмуляторы. Это демонстрирует, что в ближайшие годы автоматические атаки могут появляться без предварительной публикации уязвимости.
Практический пример: ChatGPT API в обучающей платформе
Самый близкий к реальному миру случай уже задокументирован в коммерческом тестировании безопасности. Компания внедрила ChatGPT API в систему онлайн‑обучения, позволяя пользователям задавать вопросы и получать ответы в виде HTML‑страниц.
Pentesters обнаружили, что сформировав запрос, в котором описание задачи заставляло модель включить в ответ «встроенный» JavaScript‑payload, они могли получить рабочий XSS‑вектор.
Сценарий выглядел так:
- Пользователь отправлял запрос типа «Сгенерируй страницу с примером кода, где будет отображаться переменная X».
- Модель, пытаясь выполнить запрос, включала
<script>alert('XSS')</script>в ответ. - Поскольку платформа выводила полученный HTML без дополнительного санитайза, скрипт исполнялся в браузере конечного пользователя.
Это демонстрирует, что даже «безопасные» точки интеграции LLM (например, генерация учебного контента) могут стать неожиданным источником XSS‑атаки, если не реализовать строгий контроль над выводом.
Методика аудита 60 full‑stack сниппетов
Для проверки готовности к новым угрозам специалисты провели аудит 60 типовых фрагментов кода, охватывающих как клиентскую, так и серверную часть.
- Сбор сниппетов – включены формы ввода, шаблоны рендеринга, API‑эндпоинты и микросервисы.
- Статический анализ – поиск мест, где ввод проходит через
innerHTML,document.write,eval, а также через шаблонизаторы без экранирования. - Динамический тест – автоматический запуск каждого сниппета в изолированной среде, подача разнообразных XSS‑payload (обычные, DOM‑based, polyglot).
- Отчёт о покрытии – метрика, показывающая процент уязвимых точек (в среднем 38 %).
Особый акцент делался на сценарии, где данные проходят через несколько слоёв (например, серверный API → JSON → клиентский рендеринг). Многие уязвимости проявлялись только после цепочки трансформаций, что усложняет их обнаружение традиционными сканерами.
Что делать разработчикам
- Контролировать вывод на каждом уровне: даже если серверный код «санитайзит» данные, клиентский рендеринг (React, Vue, Angular) может вновь открыть возможность XSS, если использовать небезопасные свойства (
dangerouslySetInnerHTML,v-html). - Внедрять CSP (Content Security Policy): строгие политики ограничивают выполнение инлайн‑скриптов и загрузку внешних ресурсов, снижая эффективность большинства XSS‑payload.
- Изолировать LLM‑интерфейсы: вывод, генерируемый моделью, должен проходить через отдельный слой санитайза, независимый от обычных пользовательских форм.
- Тестировать автоматизированными агентами: использовать LLM‑агенты в качестве «положительного» теста, позволяя им искать уязвимости в вашем собственном коде. Это поможет обнаружить те сценарии, которые традиционные сканеры пропускают.
- Обновлять зависимости: многие XSS‑проблемы скрываются в сторонних библиотеках (шаблонизаторы, UI‑компоненты). Регулярный аудит зависимостей и применение патчей критически важны.
Автономные модели уже доказали, что могут превзойти человеческие и традиционные инструменты в поиске XSS. Понимание их возможностей и внедрение многоуровневой защиты – единственный способ сохранить безопасность современных веб‑приложений.