Unsichere Ausgabeverarbeitung

Unsichere (oder unsachgemäße) Ausgabeverarbeitung bezeichnet das Versäumnis, die von einem großen Sprachmodell erzeugten Ausgaben zu validieren, zu bereinigen oder zu kodieren, bevor sie an nachgelagerte Systeme weitergegeben, in Benutzeroberflächen dargestellt oder in Backend-Prozessen ausgeführt werden.

Was ist unsichere Ausgabeverarbeitung?

Wenn Anwendungen LLMs integrieren, empfangen sie in der Regel generierten Text und leiten ihn an anderer Stelle weiter: an einen Browser, eine Datenbankabfrage, einen Systembefehl oder eine andere Anwendungskomponente. Eine unsichere Ausgabeverarbeitung liegt vor, wenn diese generierten Inhalte verwendet werden, ohne zuvor zu überprüfen, ob sie sicher sind.

Das Kernproblem ist Vertrauen. Entwickler gehen häufig davon aus, dass die Ausgabe vorhersehbar und unbedenklich ist, weil sie den Prompt oder das Modell kontrollieren. Das ist jedoch nicht immer der Fall. LLMs generieren Antworten auf der Grundlage von Mustern, die sie aus Trainingsdaten gelernt haben und die durch Benutzereingaben beeinflusst werden. Ein sorgfältig formulierter Prompt kann das Modell dazu veranlassen, Ausgaben zu erzeugen, die ausführbaren Code, schädliche Skripte, SQL-Fragmente oder Systembefehle enthalten. Diese werden von der Anwendung dann so verarbeitet, als handele es sich um vertrauenswürdige Daten.

Diese Schwachstelle ähnelt herkömmlichen Injection-Schwachstellen wie Cross-Site-Scripting (XSS), bei denen unzureichend abgesicherte Benutzereingaben zur Ausführung von Code in einem Browser führen. Der Unterschied besteht darin, dass die „Benutzereingabe“ in diesem Fall die Ausgabe des Modells ist, die indirekt durch Prompt-Injection manipuliert werden oder sich schlicht aus den Antwortmustern des Modells ergeben kann.

Eine unsichere Verarbeitung von Ausgaben wird zum Sicherheitsproblem, wenn die Anwendung die Ausgabe des LLM nicht mit derselben Vorsicht behandelt wie andere nicht vertrauenswürdige externe Eingaben. Ohne Validierung und Kodierung kann diese Ausgabe Sicherheitslücken in jedem System verursachen, das sie empfängt.

Warum ist eine unsichere Ausgabeverarbeitung gefährlich?

Gängige Sicherheitspraktiken gehen von vorhersehbaren Eingabequellen aus. Formulare verfügen über festgelegte Felder. APIs haben definierte Schemas. Benutzereingaben gelangen über bekannte Kanäle in das System. Die Ausgabe von LLMs stellt diese Annahmen infrage, da sie dynamisch generiert und durch Prompts beeinflusst wird, die möglicherweise schädliche Inhalte enthalten, und praktisch jede beliebige Zeichenfolge erzeugen kann.

Diese Unvorhersehbarkeit macht eine unsichere Verarbeitung von Ausgaben für LLM-gestützte Anwendungen besonders gefährlich. Ein Modell kann Tausende Male gültige, hilfreiche Antworten generieren und dann plötzlich eine Antwort mit einem Skript-Tag oder Shell-Befehl ausgeben, weil sich der Prompt in eine unerwartete Richtung entwickelt hat. Sicherheitskontrollen, die auf einer begrenzten Mustererkennung oder Positivlisten beruhen, können nur schwer jede mögliche Ausgabe vorhersehen.

Die Angriffsfläche vergrößert sich auch dadurch, dass die Ausgaben von LLMs häufig an mehrere nachgelagerte Systeme weitergeleitet werden. Eine einzelne Antwort kann in einem Browser dargestellt, in einer Datenbank protokolliert und an eine API übergeben werden. Jedes Zielsystem weist eigene Schwachstellen auf, und eine unsichere Verarbeitung der Ausgabe kann an jeder Stelle einen Ansatzpunkt für Angriffe bieten.

Darüber hinaus kann sich das Verhalten von LLMs im Laufe der Zeit ändern, wenn Modelle aktualisiert oder feinabgestimmt werden. Ausgaben, die unter einer Modellversion sicher waren, können unter einer anderen ausnutzbar werden. Anwendungen, die Ausgaben nicht grundsätzlich als nicht vertrauenswürdig behandeln, bergen ein latentes Risiko, das erst zutage tritt, wenn sich die Bedingungen ändern.

Wie kommt es zu einer unsicheren Ausgabeverarbeitung?

Eine unsichere Ausgabeverarbeitung nutzt die Diskrepanz zwischen den von einem LLM generierten Inhalten und deren Interpretation durch nachgelagerte Systeme aus. Angreifer manipulieren Prompts, um das Modell dazu zu bringen, Ausgaben zu erzeugen, die bei einer Verarbeitung ohne vorherige Bereinigung unbeabsichtigtes Verhalten im empfangenden System auslösen.

• Nicht vertrauenswürdige Ausgabe als aktive Eingabe: LLM-Ausgaben sind Textzeichenfolgen, die jedoch ausführbare Inhalte enthalten können: JavaScript, HTML, SQL, Shell-Befehle oder Markdown mit eingebetteten Skripten. Wenn eine Anwendung diese Ausgabe ohne Bereinigung direkt an einen Interpreter, eine Shell oder eine Rendering-Engine weitergibt, wird der Inhalt ausgeführt. Ein Prompt, der darauf ausgelegt ist, eine Antwort mit <script>-Tags zu erzeugen, wird beispielsweise zu einer XSS-Nutzlast, wenn die Ausgabe ohne Kodierung in eine Webseite eingefügt wird.
• In Client-Browsern oder Benutzeroberflächen gerenderte Ausgaben: Wenn von einem LLM generierte Inhalte in einem Browser oder einer Anwendungsoberfläche angezeigt werden, können darin eingebettetes HTML oder JavaScript im Kontext des Benutzers ausgeführt werden. Dadurch entstehen Möglichkeiten für Cross-Site-Scripting, Session-Hijacking, den Diebstahl von Zugangsdaten oder die Manipulation der Benutzeroberfläche. Chatbots, Inhaltsgeneratoren und KI-Assistenten, die Modellausgaben direkt rendern, sind besonders gefährdet, wenn sie auf die Ausgabecodierung verzichten.
• Backend-Ausführung und Rechteausweitung: Die schwerwiegendsten Fälle treten auf, wenn die Ausgabe eines LLM Backend-Systeme erreicht, die Code ausführen können. Wird die Ausgabe ohne Bereinigung an eine Shell, eine eval()-Funktion oder eine Datenbankabfrage übergeben, können Angreifer Code aus der Ferne ausführen, Daten exfiltrieren oder ihre Rechte ausweiten. Ein Modell, das dazu verleitet wird, eine gültige SQL-Injection-Zeichenfolge oder einen Systembefehl zu erzeugen, kann das gesamte Backend kompromittieren, wenn die Anwendung diese Ausgabe ausführt.

Häufige Beispiele und reale Angriffsszenarien

Die unsichere Verarbeitung von Ausgaben zeigt sich in Anwendungen mit LLM-Integration in mehreren typischen Mustern.

Ein Kundenservice-Chatbot, der LLM-Antworten ohne Maskierung als HTML darstellt, kann als XSS-Angriffsvektor dienen. Ein Angreifer gibt einen Prompt ein, der das Modell dazu bringen soll, ein Script-Tag in seine Antwort aufzunehmen. Wird die Antwort im Browser eines anderen Benutzers dargestellt, wird das Skript ausgeführt und kann dabei Sitzungstoken stehlen oder den Benutzer auf eine Phishing-Website umleiten.

Anwendungen, die LLM-Ausgaben zum Erstellen von Datenbankabfragen verwenden, sind ebenfalls dem Risiko von SQL-Injections ausgesetzt. Wird ein Modell aufgefordert, eine Suchabfrage für Produkte zu generieren, und erstellt ein Angreifer eine Eingabe, die das Modell dazu veranlasst, ; DROP TABLE users;-- an seine Antwort anzuhängen, führt eine Anwendung, die diese Ausgabe ohne Parametrisierung in eine SQL-Anweisung einfügt, den schädlichen Befehl aus.

Darüber hinaus sind CI/CD-Pipelines, die von LLMs generierten Code oder entsprechende Konfigurationen einbinden, anfällig für Befehlsinjektionen. Ein Modell, das ein Bereitstellungsskript erstellen soll, könnte so manipuliert werden, dass es einen Reverse-Shell-Befehl einfügt. Führt die Pipeline das Skript ungeprüft aus, erhält der Angreifer Zugriff auf die Build-Infrastruktur.

Server-Side Request Forgery kann ebenfalls durch eine unsichere Verarbeitung von Ausgaben entstehen. Ein LLM, das auf Grundlage von Benutzereingaben URLs oder API-Aufrufe generiert, könnte dazu verleitet werden, Anfragen an interne Netzwerkressourcen zu erzeugen. Führt die Anwendung diese Anfragen ohne Validierung aus, können Angreifer interne Systeme auskundschaften oder Daten exfiltrieren.

Risiken bei agentenbasierter KI und RAG-Architekturen

Mit der zunehmenden Verbreitung und Weiterentwicklung moderner KI-Anwendungen in Unternehmen verändern sich auch die Risiken einer unsicheren Verarbeitung von Ausgaben. Modelle liefern inzwischen Eingaben und Anweisungen an verbundene Anwendungen, Tools, APIs, Datenbanken und Agenten. Diese Vernetzung eröffnet böswilligen Akteuren Möglichkeiten, autonome KI-Agenten mithilfe indirekter Prompt-Injection-Techniken dazu zu verleiten, nicht genehmigte API- oder Tool-Aufrufe auszuführen, schädliche Schreibvorgänge in Datenbanken vorzunehmen oder Daten aus RAG-Pipelines (Retrieval-Augmented Generation) zu extrahieren.

Die zunehmenden autonomen Fähigkeiten und der immer häufigere Zugriff von Agenten auf geschäftskritische Systeme machen es erforderlich, Ausgaben zu validieren und zu bereinigen, bevor sie nachgelagerte Systeme oder Tools erreichen. Jede Ausgabe, die über die festgelegten Berechtigungen hinausgeht, muss eingeschränkt werden.

So verhindern Sie eine unsichere Ausgabeverarbeitung

Um eine unsichere Verarbeitung von Ausgaben zu verhindern, müssen LLM-Ausgaben mit derselben Sorgfalt behandelt werden wie nicht vertrauenswürdige Benutzereingaben. Die folgenden Maßnahmen können dazu beitragen, die Gefährdung durch gängige Angriffsvektoren zu verringern:

• Behandeln Sie LLM-Ausgaben als nicht vertrauenswürdige Eingaben: Verfolgen Sie bei allen Zero-Trust-Ansatz gegenüber allen modellgenerierten Inhalten. Unabhängig davon, wie der Prompt formuliert wurde oder welche Einschränkungen angewendet wurden, sollten Sie davon ausgehen, dass die Ausgabe schädliche oder fehlerhafte Inhalte enthalten kann. Validieren und bereinigen Sie sie vor jeder weiteren Verwendung.
• Validierung und Bereinigung der Ausgabe: Wenden Sie eine dem jeweiligen Kontext entsprechende Kodierung an, bevor Sie die Ausgabe des LLM darstellen oder ausführen. Kodieren Sie in Browsern angezeigte Ausgaben als HTML. Verwenden Sie parametrisierte Datenbankabfragen, anstatt Modellausgaben mit SQL-Zeichenfolgen zu verketten. Maskieren Sie Shell-Metazeichen, wenn die Ausgabe an Systembefehle übergeben werden muss. Verwenden Sie nach Möglichkeit Positivlisten, um die Ausgabe auf erwartete Muster zu beschränken.
• Strenge Zugriffskontrollen und Prinzip der geringsten Rechte: Beschränken Sie die Berechtigungen von Komponenten, die LLM-Ausgaben verarbeiten. Wenn ein Dienst modellgenerierte Befehle ausführt, schränken Sie ein, welche Befehle er ausführen und auf welche Ressourcen er zugreifen darf. Isolieren Sie die LLM-bezogene Verarbeitung von sensiblen Systemen. Wenden Sie das Prinzip der geringsten Rechte an, damit selbst eine erfolgreiche Ausnutzung nur begrenzte Auswirkungen hat.
• Menschliche Überprüfung und Filterung der Ausgaben: Bei risikoreichen Anwendungsfällen wie der Codegenerierung, Finanztransaktionen oder administrativen Aktionen sollte vor der Ausführung eine menschliche Überprüfung vorgeschrieben werden. Implementieren Sie automatisierte Filter, um Ausgaben zu kennzeichnen oder zu blockieren, die bekannten gefährlichen Mustern entsprechen. Verwenden Sie Inhaltsklassifikatoren, um potenziell schädliche Ausgaben zu erkennen, bevor sie nachgelagerte Systeme erreichen.
• Protokollierung, Überwachung und Auditierung: Führen Sie detaillierte Protokolle über die Ausgaben des LLM und deren Verwendung in der gesamten Anwendung. Überwachen Sie Anomalien wie unerwartete Befehlsfolgen, ungewöhnliche Ausgabemuster oder Fehler in nachgelagerten Systemen, die auf Ausnutzungsversuche hindeuten könnten. Prüfen Sie die Protokolle regelmäßig, um Lücken bei den Kontrollen zur Verarbeitung von Ausgaben zu identifizieren.

LLM-Risikorahmen und Branchenleitlinien

Die unsichere Verarbeitung von Ausgaben gilt in neuen Sicherheitsframeworks für LLMs als erhebliche Schwachstelle. Die OWASP Top 10 für LLMs stufen sie als kritisches Problem ein und weisen auf das Risiko hin, ungeprüfte Modellausgaben an Backend-Funktionen, Browser oder andere ausführungsfähige Systeme weiterzugeben.

Das Framework empfiehlt, die Ausgaben von LLMs grundsätzlich als nicht vertrauenswürdig zu behandeln, Techniken zur Eingabevalidierung auf modellgenerierte Inhalte anzuwenden und mehrschichtige Sicherheitsstrategien zu implementieren, die sich zur Verhinderung schädlicher Ausgaben nicht ausschließlich auf Prompt Engineering oder Modellbeschränkungen stützen.

Sicherheit generativer KILeitlinien von Branchenverbänden und Anbietern untermauern diese Empfehlungen. Zu den wiederkehrenden Kernthemen gehören die standardmäßige Ausgabecodierung, die strikte Trennung von LLM-generierten Inhalten und Ausführungskontexten sowie die kontinuierliche Überwachung auf Anomalien in der Ausgabe.

Organisationen, die LLMs in Produktivsysteme integrieren, sollten ihre Sicherheitskontrollen an diesen Frameworks ausrichten und die unsichere Verarbeitung von Ausgaben in ihre Bedrohungsmodelle aufnehmen. Mit der zunehmenden Verbreitung von LLMs wächst die Angriffsfläche, sodass proaktive Schutzmaßnahmen nicht mehr als fortschrittliche Praxis, sondern als grundlegende Anforderung gelten.

Anzeichen und häufige Fehler

Mehrere Anzeichen deuten darauf hin, dass eine Anwendung möglicherweise für eine unsichere Ausgabeverarbeitung anfällig ist.

Der häufigste Fehler besteht darin, der Ausgabe eines LLM standardmäßig zu vertrauen. Entwickler gehen davon aus, dass die Ausgabe sicher ist, weil sie den Prompt selbst verfasst haben. Dabei werden sowohl der Einfluss von Benutzereingaben auf das Verhalten des Modells als auch die inhärente Unvorhersehbarkeit generativer Modelle außer Acht gelassen.

Wird auf die Bereinigung verzichtet, weil die Ausgabe „wie Text aussieht“, entstehen Sicherheitslücken, wenn dieser Text eingebetteten Code oder Befehle enthält. Selbst unauffällig wirkende Antworten können Schadcode enthalten, der bei der Verarbeitung durch nachgelagerte Systeme aktiviert wird.

Die automatische Ausführung von LLM-Ausgaben ohne Validierung ist ein schwerwiegendes Anti-Pattern. Anwendungen, die Modellausgaben ungeprüft direkt an eval(), exec(), oder Shell-Interpreter übergeben, eröffnen direkte Wege zur Ausführung von Code.

Die direkte Einbettung von Ausgaben in Benutzeroberflächen oder Datenbankabfragen ohne entsprechende Kodierung setzt Anwendungen XSS- und Injection-Angriffen aus. Das bequeme Einfügen von Modellantworten in Vorlagen ohne Escaping birgt vermeidbare Risiken.

Anzeichen für eine mögliche Ausnutzung sind unter anderem unerwartete Fehler in nachgelagerten Systemen, auffällige Protokolleinträge mit ungewöhnlichen Befehlen oder Abfragen sowie Meldungen von Benutzern über merkwürdiges Verhalten in LLM-gestützten Benutzeroberflächen. Die Überwachung dieser Indikatoren trägt dazu bei, Probleme durch eine unsichere Verarbeitung von Ausgaben frühzeitig zu erkennen.

Wie geht F5 mit unsicherer Ausgabeverarbeitung um?

F5 begegnet der unsicheren Verarbeitung von Ausgaben durch Kontrollen auf der Datenverkehrs- und Anwendungsebene, wo LLM-Ausgaben mit nachgelagerten Systemen und Benutzern interagieren.

F5 AI Guardrails ist ein integraler Bestandteil der F5 AI Security Platform und setzt Richtlinien für den Austausch zwischen KI-Anwendungen, Agenten und Benutzern durch. Dazu gehört auch die Validierung von Ausgaben, bei der Modellantworten geprüft werden, bevor sie Backend-Systeme oder Client-Anwendungen erreichen. So können Unternehmen Ausgaben erkennen und blockieren, die potenziell schädliche Inhalte wie Prompt-Injections, Befehlssequenzen oder unerwartete Datenmuster enthalten.

Bei Webanwendungen, die von LLMs generierte Inhalte darstellen, Funktionen der F5 Web Application Firewall werden Verhaltensanalysen und signaturbasierte Erkennung eingesetzt, um Ausgaben zu identifizieren, die XSS, Injection-Angriffe oder andere clientseitige Schwachstellen auslösen könnten. Der Schutz erstreckt sich auch auf APIs, die LLM-Ausgaben verarbeiten. Dabei werden ungewöhnliche Nutzdaten überwacht und die Schemavalidierung durchgesetzt.

F5 Distributed Cloud Services integrieren Schutzmaßnahmen in Hybrid- und Multi-Cloud-Bereitstellungen und gewährleisten eine einheitliche Kontrolle der Ausgabeverarbeitung, unabhängig davon, wo LLM-Workloads ausgeführt werden. Protokollierungs- und Transparenzfunktionen unterstützen die Erfüllung von Audit-Anforderungen und ermöglichen es Sicherheitsteams, den Fluss von LLM-Ausgaben durch die Anwendungsinfrastruktur zu überwachen.

Durch die Platzierung von Kontrollen an den Stellen, an denen LLM-Ausgaben in Anwendungen gelangen und die Benutzer erreichen, unterstützt F5 Unternehmen dabei, die Bereinigung von Ausgaben standardmäßig durchzusetzen, anstatt sich ausschließlich auf die Implementierung auf Anwendungsebene zu verlassen.

Häufig gestellte Fragen

Wie klassifiziert OWASP die unsichere Verarbeitung von Ausgaben, und warum unterscheidet sie sich von anderen LLM-Risiken?

OWASP definiert unsichere Ausgabeverarbeitung als unzureichende Validierung, Bereinigung und Verarbeitung der von LLMs generierten Ausgaben. Sie unterscheidet sich von anderen Risiken dadurch, dass sie sich speziell auf Probleme bezieht, die entstehen, wenn Ausgaben ohne angemessene Aufsicht, Kontrollen und Governance an nachgelagerte Nutzer weitergegeben werden.

Was ist der Unterschied zwischen Ausgabecodierung und Eingabevalidierung zur Verhinderung von XSS in KI-Anwendungen?

Der Unterschied zwischen Eingabevalidierung und Ausgabecodierung zur Verhinderung von XSS in KI-Anwendungen besteht darin, dass die Eingabevalidierung die in ein Anwendungssystem eingegebenen Daten prüft, während die Ausgabecodierung die generierten Inhalte absichert, bevor sie an die Benutzer zurückgesendet werden. Bei der Eingabevalidierung werden die in eine Anwendung eingehenden Daten geprüft, um Eingaben abzulehnen, die nicht den festgelegten Regeln oder erwarteten Formaten entsprechen. Die Ausgabecodierung wandelt potenziell gefährliche Eingaben in eine Form um, die sicher als Daten statt als ausführbarer Code dargestellt werden kann.

Wie kann eine indirekte Prompt-Injection durch unsichere Ausgabeverarbeitung zur Ausführung von Remote-Code (Remote Code Execution, RCE) führen?

Indirekte Prompt-Injection kann für RCE genutzt werden, indem schädliche Anweisungen in die dem Modell bereitgestellten Inhalte eingebettet werden. Diese Anweisungen können das Modell dazu veranlassen, Befehle oder ausführbare Dateien zu erzeugen und die Ausgabe anschließend an andere Tools oder Systeme weiterzugeben, die sie als legitim behandeln.

Wie verhindere ich SQL-Injection und serverseitige Anfragenfälschung (Server-Side Request Forgery, SSRF), wenn ich LLMs mit Datenbanken oder internen APIs verbinde?

Um SQL-Injection und serverseitige Anfragenfälschung (SSRF) bei der Anbindung von Datenbanken oder internen APIs zu verhindern, sollten Ausgaben von LLMs – einschließlich Befehlen, Parametern, URLs und Tool-Argumenten – als nicht vertrauenswürdige Daten und nicht als ausführbare Anweisungen behandelt werden. Validierungslösungen, Positivlisten für APIs, parametrisierte Abfragen und Zugriffsrechte nach dem Prinzip der geringsten Privilegien können dazu beitragen, die Risiken zu mindern.

Was ist der Unterschied zwischen LangChain Guardrails, NVIDIA NeMo Guardrails und Web Application Firewalls (WAFs)?

LangChain Guardrails, NVIDIA NeMo Guardrails und WAFs sind komplementäre Lösungen. Der Hauptunterschied besteht darin, dass sie jeweils unterschiedliche Aspekte von KI-Systemen in Unternehmen schützen. LangChain Guardrails dienen der Validierung von Aufgaben und Agenten und sind als Middleware in den Anwendungscode des LLM integriert. NVIDIA NeMo Guardrails werden der LLM-Orchestrierung vorgeschaltet, um mehrstufige Dialoge zu steuern und die thematische Ausrichtung sicherzustellen. WAFs werden am Netzwerkrand eingesetzt, um vor Bedrohungen wie SQL-Injection, XSS und DDoS-Angriffen zu schützen.