🧨 Небезопасная обработка вывода LLM (LLM05): XSS, SSRF, SQL-инъекция и RCE через ответ модели

Целевая аудитория: Команды, чьи приложения передают ответ LLM дальше по системе — в браузер, SQL-запрос, системный shell, файловый путь или внешний API — то есть везде, где вывод модели становится входом для другого компонента и может пересечь границу доверия.

Небезопасная обработка вывода LLM (improper output handling) — это передача ответа модели в downstream-компонент (SQL, shell, HTML/браузер, файловую систему, API) без валидации, санитизации и экранирования, как если бы этот вывод был доверенным. Проблема не в том, что модель «ошиблась», а в том, что её ответ — по сути недоверенный текст — попадает напрямую в исполнительный приёмник (sink) и интерпретируется как код или команда. Этот класс зафиксирован в OWASP Top 10 для LLM 2025 как LLM05:2025 Improper Output Handling. Результат — XSS и CSRF в браузере, SSRF и эскалация привилегий на бэкенде, SQL-инъекция при запуске сгенерированного запроса без параметризации, path traversal при построении путей и RCE при исполнении вывода в shell. На этой странице мы разбираем векторы небезопасной обработки вывода и показываем, как их закрывает SYNTREX — защитный слой платформы Spectorn (набор движков обнаружения и блокировки, который работает в составе Spectorn и разворачивается standalone на внутреннем контуре заказчика).

Часть серии угроз: OWASP LLM Top 10 · Prompt Injection · Утечка данных · Избыточные полномочия.

Почему вывод LLM нельзя считать доверенным

Ключевой принцип LLM05 формулируется в одну фразу: относитесь к любому выводу модели как к недоверенному вводу — применяйте к нему те же контроли, что и к произвольной строке от внешнего пользователя. Причина в том, что языковая модель не источник истины и не доверенный сервис: её ответ формируется из системного промпта, пользовательского запроса, документов RAG и вывода инструментов — то есть из потока, в который атакующий мог пронести инструкцию через инъекцию промпта. «Так сказала модель» — это не валидация и не санкция на исполнение.

Опасность реализуется в момент, когда ответ пересекает границу доверия и попадает в исполнительный приёмник. Типичные downstream-sinks:

Браузер / DOM. Ответ модели рендерится как HTML или Markdown, исполняется как JS — отражённый или хранимый XSS, CSRF.
SQL-движок. LLM генерирует запрос (Text2SQL) или его фрагмент, и приложение запускает строку без параметризации — SQL-инъекция, разрушительные операции вроде DELETE без WHERE.
Системный shell. Вывод модели передаётся в exec/eval/os.system или исполняется как сгенерированный код в CI/CD — удалённое выполнение кода (RCE).
Файловая система. Ответ участвует в построении пути к файлу — path traversal через ../, чтение и запись вне разрешённого каталога.
Исходящий HTTP / внешний API. Из вывода модели собирается URL, который бэкенд затем запрашивает, — SSRF, доступ к внутренним сервисам и метаданным облака.

Важно отличать LLM05 от переоценки модели (overreliance) и дезинформации: LLM05 — это не про фактическую точность ответа, а про то, что вывод пересекает границу доверия и попадает в исполнительный sink без обработки. Даже идеально правильный по смыслу ответ становится уязвимостью, если приложение исполняет его как доверенный код. Поэтому контроль строится не на «проверке правды», а на инспекции потока на опасные конструкции и на безопасном кодировании самого приёмника.

🛑 Векторы небезопасной обработки вывода и как SYNTREX их закрывает

1. XSS через рендеринг ответа модели в браузере

Риск: Приложение вставляет ответ модели в страницу как HTML или Markdown и отдаёт браузеру без экранирования. Модель (по своей генерации или под действием инъекции) возвращает <script>, обработчик события onerror=, javascript:-ссылку или Markdown-конструкцию, которая разворачивается в исполняемый HTML. Браузер исполняет это как код в контексте сессии пользователя — отражённый или хранимый XSS, кража cookie/токенов, CSRF-действия от лица жертвы. Особенно опасны чат-интерфейсы, которые рендерят Markdown «как есть».

OWASP LLM05:2025 Improper Output Handling · MITRE ATLAS AML.T0054 (Indirect Prompt Injection).

Защита SYNTREX:

Движки/компоненты: output_scanner, injection, Shield DMZ.
output_scanner инспектирует ответ модели на исполняемые HTML/JS-конструкции (теги <script>, inline-обработчики событий, javascript:-схемы, опасный Markdown) до того, как ответ дойдёт до клиента, и блокирует или заменяет его безопасной заглушкой.
injection ловит инструкцию-источник во входящем контенте, которая принуждает модель сгенерировать XSS-нагрузку; Shield DMZ инспектирует каждый ответ модели на рубеже перед доставкой в браузер.

Что SYNTREX честно НЕ заменяет: контекстное экранирование на стороне приёмника (HTML-encode при выводе в DOM), Content-Security-Policy и безопасный рендеринг Markdown с белым списком тегов. SYNTREX перехватывает опасные конструкции в потоке ответа, но финальное экранирование под конкретный контекст вывода — обязанность самого фронтенда. Это эшелонированная защита, а не замена кодированию на sink.

2. SQL-инъекция через сгенерированный моделью запрос (Text2SQL)

Риск: LLM переводит запрос пользователя на естественном языке в SQL (Text2SQL) или достраивает фрагмент запроса, и приложение исполняет полученную строку напрямую, без параметризации. Через инъекцию во входе атакующий принуждает модель сгенерировать разрушительный или извлекающий запрос: DELETE FROM users без WHERE, UNION SELECT к чужим таблицам, ; DROP TABLE. Поскольку запрос «легитимно» сгенерирован вашим же ассистентом, классические WAF-фильтры пользовательского ввода его не видят — он рождается уже внутри периметра.

OWASP LLM05:2025 Improper Output Handling · MITRE ATLAS AML.T0054 (Indirect Prompt Injection).

Защита SYNTREX:

Движки/компоненты: output_scanner, injection.
output_scanner распознаёт в выводе модели паттерны SQL-инъекции и опасные DML/DDL-конструкции (DELETE/UPDATE без условия, stacked queries, UNION-инъекции, DROP) до того, как строка уйдёт в драйвер БД, и блокирует опасный запрос.
injection перехватывает инструкцию во входящем контенте, которая нацеливает Text2SQL на разрушительный или извлекающий запрос.

Что SYNTREX честно НЕ заменяет: параметризованные запросы (prepared statements) и доступ к БД под учёткой с минимальными правами. Правильная архитектура Text2SQL отделяет структуру запроса от данных и никогда не конкатенирует вывод модели в SQL-строку. SYNTREX страхует этот рубеж на потоке, но безопасная работа с БД должна быть закодирована на стороне приёмника.

3. Command injection и RCE через исполнение вывода в shell или CI/CD

Риск: Ответ модели передаётся в системный вызов — exec, eval, subprocess, os.system — или исполняется как сгенерированный код. Типичные сценарии: ассистент-«копилот» генерирует shell-команду, которую обвязка запускает автоматически; LLM-агент пишет код, который CI/CD-пайплайн выполняет без ревью; плагин подставляет вывод модели в шаблон команды. Любая инъекция, дотянувшаяся до этого вывода, превращается в удалённое выполнение произвольного кода на хосте — самый тяжёлый исход LLM05.

OWASP LLM05:2025 Improper Output Handling · MITRE ATLAS AML.T0054 (Indirect Prompt Injection).

Защита SYNTREX:

Движки/компоненты: output_scanner, injection, Shield DMZ.
output_scanner инспектирует поток на исполняемые shell-конструкции и опасные паттерны кода (пайпы в sh, curl … | bash, разделители команд ;/&&/$(...), обратные кавычки) и блокирует вызов до его исполнения на хосте.
injection распознаёт нагрузку-команду, внедрённую через входной контент или вывод инструмента; Shield DMZ блокирует или заменяет опасный ответ безопасной заглушкой перед передачей в исполнитель.

Что SYNTREX честно НЕ заменяет: песочницу для исполнения кода (изолированный контейнер без доступа к секретам и сети), обязательное человеческое ревью перед запуском сгенерированного кода в CI/CD и принцип «вывод модели не исполняется напрямую». SYNTREX ловит опасные конструкции в транзите, но sandboxing и review-gate должны существовать независимо от него.

4. SSRF через URL, собранный из вывода модели

Риск: Приложение строит URL для исходящего запроса из ответа модели — например, агент «сходи по этой ссылке и резюмируй», где адрес продиктован выводом LLM, или бэкенд подставляет домен из ответа в шаблон запроса. Через инъекцию атакующий подменяет цель на внутренний адрес: http://169.254.169.254/ (метаданные облака), http://localhost:6379 (внутренний Redis), адрес сервиса во внутренней сети. Бэкенд, имея сетевой доступ изнутри периметра, выполняет запрос — Server-Side Request Forgery, доступ к недостижимым снаружи сервисам и кража облачных кредов.

OWASP LLM05:2025 Improper Output Handling · MITRE ATLAS AML.T0054 (Indirect Prompt Injection).

Защита SYNTREX:

Движки/компоненты: output_scanner, injection.
output_scanner распознаёт в выводе модели исходящие URL с подозрительными целями (внутренние и loopback-адреса, эндпоинты облачных метаданных, нестандартные порты внутренних сервисов) до того, как бэкенд выполнит запрос.
output_scanner блокирует или редактирует такой ответ в содержимом, а injection перехватывает инструкцию, подменяющую цель запроса на внутренний адрес. Это инспекция контента на шлюзе, а не сетевой egress-фильтр — строгий контроль egress реализуется на сетевом и серверном уровне (см. ниже).

Что SYNTREX честно НЕ заменяет: серверный allow-list разрешённых доменов назначения, сетевую сегментацию и блокировку доступа к эндпоинту метаданных на уровне инфраструктуры. SYNTREX распознаёт подозрительную цель в потоке, но строгий контроль того, куда вообще может обращаться бэкенд, реализуется на сетевом и серверном уровне.

5. Path traversal через построение файлового пути из ответа

Риск: Вывод модели участвует в формировании пути к файлу — имя отчёта, путь к шаблону, ключ в файловом кэше, имя вложения. Если приложение конкатенирует ответ в путь без нормализации, инъекция протаскивает ../../../etc/passwd или абсолютный путь, и приложение читает или перезаписывает файлы вне разрешённого каталога. Это и утечка чувствительных файлов, и потенциальная порча данных, если вывод используется для записи.

OWASP LLM05:2025 Improper Output Handling · MITRE ATLAS AML.T0054 (Indirect Prompt Injection).

Защита SYNTREX:

Движки/компоненты: output_scanner, injection.
output_scanner инспектирует вывод на конструкции обхода каталога (../, кодированные варианты %2e%2e, абсолютные и UNC-пути) до того, как строка попадёт в файловую операцию, и блокирует опасное значение.
injection распознаёт инструкцию во входном контенте, которая нацеливает построение пути на выход за пределы рабочего каталога.

Что SYNTREX честно НЕ заменяет: канонизацию и валидацию пути на стороне приёмника (резолв realpath с проверкой, что результат внутри разрешённого корня) и запуск под учёткой ФС с минимальными правами. SYNTREX страхует поток, но безопасная работа с путями кодируется в самом файловом слое приложения.

6. Утечка секретов и PII через вывод в downstream-логи и приёмники

Риск: Ответ модели несёт чувствительные значения — токен, API-ключ, connection string, PII из контекста — и приложение передаёт его дальше: пишет в лог downstream-сервиса, отправляет во внешний API, складывает в очередь, рендерит в отчёт. Секрет, родившийся в выводе (например, процитированный из системного промпта или RAG-документа), без маскирования утекает в приёмник, доступ к которому шире, чем к самой LLM-сессии. Это пересечение LLM05 с утечкой данных (LLM02): опасен не сам по себе текст, а то, что он уходит в downstream-sink необработанным.

OWASP LLM05:2025 Improper Output Handling, LLM02:2025 Sensitive Information Disclosure · MITRE ATLAS AML.T0054 (Indirect Prompt Injection).

Защита SYNTREX:

Движки/компоненты: output_scanner, secret_scanner, pii, false_completion.
secret_scanner — всегда включённый инвариант: токены, ключи, пароли и connection strings маскируются в выводе до того, как он уйдёт в downstream-приёмник или лог; pii маскирует персональные данные в режиме redact, не блокируя весь ответ.
output_scanner инспектирует исходящий поток на чувствительные конструкции перед передачей дальше; false_completion распознаёт навязанное инъекцией «подтверждающее» завершение, которым модель легитимизирует выдачу секрета.

🛠️ Рекомендуемая конфигурация

Профиль инспекции вывода — приоритет на проверке ответа модели перед передачей в любой downstream-приёмник (shell, SQL, браузер, ФС, исходящий URL) плюс маскирование секретов и PII:

YAML

# syntrex.yaml — профиль инспекции вывода модели (LLM05)
version: "1.0"
mode: output_inspection

engines:
  output_scanner:
    action: block                  # инспекция ответа до передачи в downstream-sink
    detect_command_injection: true # shell / exec / eval / RCE в выводе
    detect_sqli: true              # SQL-инъекция, DELETE/UPDATE без WHERE, stacked queries
    detect_xss: true               # <script>, inline-обработчики, javascript:-схемы
    sanitize_html: true            # экранирование/очистка HTML и Markdown перед рендером
    detect_ssrf: true              # внутренние/loopback URL, эндпоинты метаданных
    detect_path_traversal: true    # ../ и кодированные варианты обхода каталога
  injection:
    action: block                  # инструкция-источник, нацеливающая опасный вывод
    inspect_tool_output: true
    confidence_threshold: 0.80
  secret_scanner: always_on        # токены/ключи/connection strings не уходят в sink
  pii:
    action: redact                 # маскируем PII, не блокируя весь ответ
    mask_character: "*"
    entities: [card, passport, phone, email, iban, ssn]
  false_completion:
    action: alert                  # навязанное «подтверждающее» завершение

shield:
  dmz: true                        # Shield DMZ инспектирует каждый ответ, блок/заглушка

audit:
  decision_logger: true            # неизменяемая цепочка (SHA-256/HMAC) решений по выводу

🚨 Правила корреляции (SOC)

Небезопасный вывод почти всегда виден как связка «инъекция во входе → опасная конструкция в ответе» или как срабатывание output_scanner прямо перед обращением к исполнительному приёмнику:

JSON

{
  "name": "INJECTION_TO_DANGEROUS_OUTPUT",
  "description": "Инъекция во входящем контенте, за которой в ответе модели появляется опасная конструкция (SQLi/XSS/shell)",
  "condition": "sequence(injection[source='external_content' OR source='tool_output', confidence>0.7], output_scanner[match_type IN ('sqli','xss','command_injection'), confidence>0.7], 15s)",
  "severity": "CRITICAL",
  "playbook": "block_response_and_alert_soc"
}

JSON

{
  "name": "OUTPUT_SCANNER_MATCH_BEFORE_EXEC",
  "description": "Срабатывание инспекции вывода непосредственно перед обращением к исполнительному приёмнику (shell/SQL/HTTP)",
  "condition": "sequence(output_scanner[match=true, match_type IN ('command_injection','sqli','ssrf','path_traversal')], downstream_sink[action='execute'], 5s)",
  "severity": "HIGH",
  "playbook": "quarantine_response_and_review_sink"
}

❓ Частые вопросы (FAQ)

Что такое небезопасная обработка вывода LLM (LLM05)? Небезопасная обработка вывода (OWASP LLM05:2025 Improper Output Handling) — это передача ответа модели в downstream-компонент (SQL, shell, браузер, файловую систему, API) без валидации, санитизации и экранирования, как если бы вывод был доверенным. Поскольку ответ LLM — по сути недоверенный текст, его попадание в исполнительный приёмник без обработки приводит к XSS, SQL-инъекции, SSRF, path traversal и RCE. SYNTREX закрывает это инспекцией потока: output_scanner распознаёт опасные конструкции в ответе до передачи в sink, а injection ловит инструкцию-источник.

Может ли LLM вызвать XSS или SQL-инъекцию? Да — не сама модель, а приложение, которое исполняет её вывод без обработки. Если ответ рендерится в браузере как HTML/Markdown без экранирования, <script> или javascript:-ссылка из вывода даёт XSS. Если сгенерированный моделью SQL (Text2SQL) исполняется без параметризации, во входе можно протащить инъекцию вроде DELETE FROM users без WHERE. output_scanner с флагами detect_xss и detect_sqli распознаёт эти конструкции в ответе до того, как он дойдёт до браузера или драйвера БД.

Как защититься от SQL-инъекции через ответ модели? Двумя слоями. Первичный, незаменимый контроль — параметризованные запросы на стороне приёмника: структура SQL отделяется от данных, и вывод модели никогда не конкатенируется в строку запроса. Поверх этого SYNTREX страхует поток: output_scanner с detect_sqli распознаёт опасные DML/DDL-конструкции и паттерны инъекции в сгенерированном запросе и блокирует его до отправки в драйвер БД, а injection ловит инструкцию, нацеливающую Text2SQL на разрушительный запрос. Параметризацию SYNTREX не заменяет — это обязанность кода работы с БД.

Почему вывод LLM нужно считать недоверенным? Потому что модель не источник истины и не доверенный сервис: её ответ собирается из системного промпта, пользовательского ввода, документов RAG и вывода инструментов — потока, в который атакующий мог пронести инструкцию через инъекцию промпта. «Так сказала модель» — это не валидация. Базовый принцип LLM05: применяйте к выводу те же контроли, что и к произвольной строке от внешнего пользователя, особенно когда он пересекает границу доверия и попадает в исполнительный приёмник.

Чем LLM05 отличается от дезинформации и галлюцинаций? Дезинформация и переоценка модели (overreliance) — это про фактическую неточность ответа: модель уверенно говорит неправду. LLM05 — про другое: вывод (даже фактически верный) пересекает границу доверия и попадает в исполнительный sink без обработки, становясь кодом или командой. Здесь опасность не в смысле текста, а в том, что приёмник исполняет его как доверенный. Поэтому защита от LLM05 — это инспекция потока на опасные конструкции и безопасное кодирование sink, а не «проверка правды».

Заменяет ли SYNTREX параметризованные запросы и экранирование? Нет, и это важная граница. SYNTREX — слой обнаружения и блокировки на потоке ответа: он перехватывает опасные конструкции (SQLi, XSS, shell, SSRF, path traversal) в транзите до того, как они дойдут до приёмника. Но безопасное кодирование самого sink — параметризованные запросы, контекстное экранирование (HTML-encode для браузера, bind-параметры для SQL), Content-Security-Policy, песочница для исполнения кода — остаётся обязательным. Это эшелонированная защита: SYNTREX ловит опасное в потоке, а приёмник всё равно должен быть закодирован безопасно.

📚 Источники

OWASP LLM05:2025 — Improper Output Handling — первоисточник по классу небезопасной обработки вывода.
OWASP Top 10 для LLM-приложений (2025) — каталог рисков LLM01–LLM10.
MITRE ATLAS — AML.T0054 (Indirect Prompt Injection): отравленный ввод как драйвер опасного вывода.
OWASP — Cross-Site Scripting (XSS) — справочник по XSS как реализации небезопасного вывода в браузере.
OWASP — Injection (SQL и команды) — справочник по инъекционным уязвимостям в исполнительных приёмниках.
NIST AI Risk Management Framework (AI RMF 1.0) — управление рисками обработки вывода AI-систем.
NIST AI 600-1 — Generative AI Profile — профиль рисков генеративного ИИ.

Связанные руководства: OWASP LLM Top 10 · Prompt Injection · Утечка данных · Избыточные полномочия AI-агентов · Supply-chain риски · Безопасность RAG-систем