Was ist unsichere Ausgabeverarbeitung in LLM-Apps, und wie führt sie zu XSS oder SSRF?
Kurzantwort
Unsichere Ausgabeverarbeitung bedeutet, dem zu vertrauen, was das Modell zurückgibt, und es ohne Validierung oder Codierung an ein nachgelagertes System weiterzureichen. Weil die Modellausgabe von Angreifern beeinflussbar ist, führt das Rendern als rohes HTML zu XSS, das Einspeisen in einen URL-Fetcher zu SSRF und das Übergeben an eine Shell oder SQL-Abfrage zu Command- oder SQL-Injection. Die Lösung ist, die Modellausgabe genauso wie nicht vertrauenswürdige Benutzereingaben zu behandeln: kontextbewusste Ausgabecodierung, Allowlisting, Sanitization und Parametrisierung, bevor sie einen Sink erreicht.
Unsichere Ausgabeverarbeitung (OWASP nennt es improper output handling) ist ein klassischer AppSec-Fehler mit KI-Hut: Die Anwendung vertraut dem, was das Modell zurückgibt, und reicht es direkt an eine nachgelagerte Komponente weiter. Der Haken ist, dass die Modellausgabe von Angreifern beeinflussbar ist — durch direkte Prompts, Jailbreaks oder indirekte Injektion in abgerufenen Daten — und daher als nicht vertrauenswürdig behandelt werden muss, genau wie jede Benutzereingabe.
Wie daraus echte Schwachstellen werden
Der Fehler tritt am Sink auf, also überall dort, wo die Ausgabe landet:
- XSS. Die App rendert die Antwort des Modells als rohes HTML/Markdown im Browser. Gibt das Modell ein
<script>oder einenonerror-Handler aus (weil ein Angreifer es dazu gebracht hat), wird es in der Sitzung des Opfers ausgeführt. - SSRF. Die App nimmt eine URL vom Modell und ruft sie serverseitig ab, sodass ein Angreifer interne Dienste oder Cloud-Metadaten-Endpunkte erreichen kann.
- Command- / SQL-Injection. Die Ausgabe wird in ein Shell-Kommando oder eine SQL-Abfrage konkateniert.
- Path Traversal, Open Redirect, Log Injection — gleiches Muster, anderer Sink.
Ein subtiler Punkt: Selbst wenn du die Eingabe des Benutzers bereinigt hast, kann das Modell eigenständig eine bösartige Payload erzeugen, sodass Eingabe-Sanitization allein den Sink nicht schützt.
Verteidigungsmaßnahmen
Wende dieselbe Disziplin an wie bei allen nicht vertrauenswürdigen Daten:
- Kontextbewusste Ausgabecodierung vor dem Rendern (HTML-, Attribut-, JS-, URL-Kontexte).
- Allowlisting und Validierung strukturierter Ausgaben (URLs, IDs, Enums) gegen strikte Schemata.
- Parametrisierung von Abfragen und kein Übergeben von Ausgaben an Shells.
- Sandboxing und Egress-Filterung für jeden serverseitigen Abruf oder jede Ausführung.
Worauf Interviewer achten
Die Denkweise, dass "Modellausgabe nicht vertrauenswürdige Eingabe ist", die Fähigkeit, den Sink für jede Schwachstelle zu benennen (XSS, SSRF, Command Injection), und der Griff zu kontextbewusster Codierung und Validierung, statt dem Prompt die Schuld zu geben.
Wahrscheinliche Anschlussfragen
- Warum ist die Modellausgabe ein Injektionsvektor, selbst wenn die Benutzereingabe bereinigt wurde?
- Welche kontextbewusste Codierung würdest du anwenden, bevor du Modellausgaben in HTML renderst?
- Wie verschärft sich dieses Risiko, wenn die Ausgabe an einen tool-nutzenden Agenten weitergegeben wird?