OWASP Top 10 для LLM 2025 · LLM05

Ненадлежащая обработка выходных данных (Improper Output Handling)

Ненадлежащая обработка выходных данных (improper output handling) — это, в частности, недостаточная проверка, очистка и обработка выходных данных, сгенерированных большими языковыми моделями, до их передачи другим компонентам и системам. Поскольку контентом, который генерирует LLM, можно управлять через входной запрос, такое поведение аналогично предоставлению пользователям косвенного доступа к дополнительной функциональности.

Описание

Ненадлежащая обработка выходных данных (improper output handling) — это, в частности, недостаточная проверка, очистка и обработка выходных данных, сгенерированных большими языковыми моделями, до их передачи другим компонентам и системам. Поскольку контентом, который генерирует LLM, можно управлять через входной запрос, такое поведение аналогично предоставлению пользователям косвенного доступа к дополнительной функциональности.

Ненадлежащая обработка выходных данных отличается от чрезмерного доверия (Overreliance): первая касается выходных данных LLM до их передачи дальше по цепочке, тогда как чрезмерное доверие связано с более широкими проблемами излишней зависимости от точности и уместности ответов LLM.

Успешная эксплуатация уязвимости ненадлежащей обработки выходных данных может привести к межсайтовому скриптингу (XSS) и подделке межсайтовых запросов (CSRF) в веб-браузерах, а также к подделке запросов на стороне сервера (SSRF), повышению привилегий или удаленному выполнению кода во внутренних (backend) системах.

Последствия этой уязвимости могут усугубляться при следующих условиях: приложение предоставляет LLM привилегии сверх предусмотренных для конечных пользователей, что делает возможными повышение привилегий или удаленное выполнение кода; приложение уязвимо для атак косвенного внедрения инструкций, которые могут позволить атакующему получить привилегированный доступ к среде целевого пользователя; сторонние расширения не проверяют входные данные должным образом; отсутствует надлежащее кодирование выходных данных с учетом контекста (например, HTML, JavaScript, SQL); мониторинг и журналирование выходных данных LLM недостаточны; отсутствуют ограничение частоты запросов (rate limiting) или обнаружение аномалий при использовании LLM.

Типовые примеры уязвимости

  1. 1. Выходные данные LLM передаются непосредственно в системную оболочку или аналогичную функцию, например exec или eval, что приводит к удаленному выполнению кода.
  2. 2. LLM генерирует JavaScript или Markdown и возвращает пользователю. Затем код интерпретируется браузером, что приводит к XSS.
  3. 3. Сгенерированные LLM SQL-запросы выполняются без надлежащей параметризации, что приводит к SQL-инъекции.
  4. 4. Выходные данные LLM используются для построения путей к файлам без надлежащей очистки, что может привести к уязвимостям обхода каталогов (path traversal).
  5. 5. Сгенерированный LLM контент используется в шаблонах электронных писем без надлежащего экранирования, что может привести к фишинговым атакам.

Меры предотвращения и смягчения

  1. 1. Рассматривайте модель как любого другого пользователя, придерживаясь подхода нулевого доверия (zero trust), и применяйте надлежащую проверку входных данных к ответам, поступающим от модели во внутренние функции.
  2. 2. Следуйте рекомендациям OWASP ASVS (Application Security Verification Standard, стандарт проверки безопасности приложений) для эффективной проверки и очистки входных данных.
  3. 3. Кодируйте выходные данные модели, возвращаемые пользователям, чтобы предотвратить нежелательное выполнение кода через JavaScript или Markdown. OWASP ASVS содержит подробные рекомендации по кодированию выходных данных.
  4. 4. Применяйте кодирование выходных данных с учетом контекста, в котором они будут использоваться (например, HTML-кодирование для веб-контента, SQL-экранирование для запросов к базе данных).
  5. 5. Используйте параметризованные запросы или подготовленные выражения (prepared statements) для всех операций с базой данных, в которых участвуют выходные данные LLM.
  6. 6. Применяйте строгие политики безопасности контента (Content Security Policy, CSP), чтобы снизить риск XSS-атак через контент, сгенерированный LLM.
  7. 7. Внедрите надежные системы журналирования и мониторинга для выявления необычных закономерностей в выходных данных LLM, которые могут указывать на попытки эксплуатации.

Примеры сценариев атак

  1. Сценарий 1. Приложение использует расширение LLM для генерации ответов в функции чат-бота. Расширение также предоставляет ряд административных функций, доступных другой, привилегированной LLM. LLM общего назначения напрямую, без надлежащей проверки выходных данных, передает свой ответ расширению, в результате чего расширение отключается на техническое обслуживание.
  2. Сценарий 2. Пользователь применяет инструмент на базе LLM для составления краткого изложения статьи с веб-сайта. Сайт содержит внедренную инструкцию, предписывающую LLM захватить конфиденциальное содержимое с сайта или из переписки пользователя. Далее LLM может закодировать конфиденциальные данные и отправить их без какой-либо проверки или фильтрации выходных данных на сервер, контролируемый атакующим.
  3. Сценарий 3. LLM позволяет пользователям составлять SQL-запросы к внутренней базе данных через интерфейс в формате чата. Пользователь запрашивает запрос на удаление всех таблиц базы данных. Если составленный LLM запрос не проверяется, все таблицы базы данных будут удалены.
  4. Сценарий 4. Веб-приложение использует LLM для генерации контента по текстовым запросам пользователей без очистки выходных данных. Атакующий может отправить специально подготовленный запрос, из-за которого LLM вернет неочищенную полезную нагрузку JavaScript, что приведет к XSS при отображении в браузере жертвы. Эту атаку сделала возможной недостаточная проверка запросов.
  5. Сценарий 5. LLM используется для генерации динамических шаблонов электронных писем для маркетинговой кампании. Атакующий манипулирует LLM так, чтобы в содержимое письма был включен вредоносный JavaScript. Если приложение не очищает выходные данные LLM должным образом, это может привести к XSS-атакам на получателей, просматривающих письмо в уязвимых почтовых клиентах.
  6. Сценарий 6. В компании-разработчике ПО LLM используется для генерации кода по запросам на естественном языке с целью ускорить разработку. При всей эффективности такой подход несет риски раскрытия конфиденциальной информации, создания небезопасных методов обработки данных или внесения уязвимостей, например SQL-инъекций. AI также может «галлюцинировать» несуществующие программные пакеты, что может побудить разработчиков загрузить зараженные вредоносным ПО ресурсы. Тщательная проверка кода (code review) и верификация предлагаемых пакетов крайне важны для предотвращения нарушений безопасности, несанкционированного доступа и компрометации систем.
Ссылки из оригинала

Дополнительные материалы

Proof Pudding (CVE-2019-20634) (AVID; moohax & monoxgas)Arbitrary Code Execution (Snyk Security Blog)ChatGPT Plugin Exploit Explained: From Prompt Injection to Accessing Private Data (Embrace The Red)New prompt injection attack on ChatGPT web version. Markdown images can steal your chat data. (System Weakness)Don’t blindly trust LLM responses. Threats to chatbots (Embrace The Red)Threat Modeling LLM Applications (AI Village)OWASP ASVS - 5 Validation, Sanitization and Encoding (OWASP AASVS)AI hallucinates software packages and devs download them – even if potentially poisoned with malware (Theregiste)