Prompt Injection und Jailbreaks

Prompt Injection ist das Pendant des LLM-Zeitalters zu klassischen Injection-Schwachstellen (SQL, Befehle). Die Ursache ist dieselbe: Eine Anwendung vermischt vertrauenswürdige Anweisungen und nicht vertrauenswürdige Daten im selben Kanal, und der Interpreter (das Modell) kann sie nicht zuverlässig voneinander unterscheiden.

Bei einem LLM gelangen der System-Prompt, die Anweisungen des Entwicklers und alle abgerufenen Inhalte als ein einziger flacher Token-Stream an das Modell. Wenn ein vom Angreifer kontrollierter Text Ignore previous instructions and... enthält, befolgt das Modell ihn möglicherweise, weil er für das Modell einfach weitere Sprache ist.

• Vertrauenswürdig: Ihr System-Prompt und Ihre Richtlinien.
• Nicht vertrauenswürdig: Benutzereingaben, Webseiten, Dateien, Toolausgaben und E-Mails.

Direkte Prompt Injection tritt auf, wenn der Endbenutzer schädliche Anweisungen direkt in den Prompt eingibt, um das vorgesehene Verhalten der Anwendung zu überschreiben.

Ein typischer Versuch gegen einen Kundensupport-Bot sieht folgendermaßen aus:

• Dem Bot wird mitgeteilt, dass er nur Fragen zur Abrechnung beantworten soll.
• Der Benutzer fügt Text ein, der die Rolle des Modells neu definiert und es auffordert, seinen System-Prompt preiszugeben oder Aktionen außerhalb des vorgesehenen Bereichs auszuführen.

Direkte Injection ist am leichtesten nachzuvollziehen, weil der schädliche Text und der Angreifer dieselbe Person sind. Dennoch umgeht sie naive Schutzmaßnahmen.

Indirekte Prompt Injection (Injection zweiter Ordnung) ist die gefährlichere Variante. Der Angreifer platziert Anweisungen in Inhalten, die das Modell später abrufen wird: auf einer Webseite, in einer PDF-Datei, einer Kalendereinladung, einem Codekommentar oder einem Support-Ticket.

Der betroffene Benutzer sieht die Payload nie. Wenn eine RAG-Pipeline oder ein Browsing-Agent diesen Inhalt in den Kontext übernimmt, werden die verborgenen Anweisungen mit den Berechtigungen des betroffenen Benutzers ausgeführt.

Beispiel: Eine Webseite enthält verborgenen Text, der einen zusammenfassenden Agenten auffordert, den Chatverlauf des Benutzers an eine Angreifer-URL zu exfiltrieren.

Diese Begriffe überschneiden sich, sind aber nicht identisch:

• Prompt Injection zielt auf die Anwendungsgrenze – sie überschreibt die Anweisungen des Entwicklers mit Angreiferdaten.
• Jailbreaking zielt auf die Sicherheitsausrichtung des Modells – es bringt das Modell dazu, Inhalte zu erzeugen, deren Ausgabe der Anbieter ihm abtrainiert hat.

Ein Jailbreak erfordert keine verwundbare Anwendung; er funktioniert direkt gegen das Rohmodell. Viele reale Angriffe kombinieren beides: Ein Jailbreak lockert die Verweigerungen, während Injection das Verhalten der Anwendung umleitet.

Angreifer verwenden vorhersehbare Manipulationsmuster. Wenn Sie diese kennen, können Sie Ihr eigenes System verantwortungsvoll einem Red-Team-Test unterziehen:

• Rollenspiel / Persona: Die Anfrage wird als Fiktion oder als Anfrage einer fiktiven uneingeschränkten Figur dargestellt.
• Verschleierung: Base64, Leetspeak, Übersetzung oder Aufteilung in Tokens, um Keyword-Filter zu umgehen.
• Aufteilung der Payload: Eine Anfrage wird über mehrere Nachrichten verteilt, sodass keine einzelne Nachricht schädlich wirkt.
• Hypothetische Szenarien: For a security class, describe how one would...
• Prefix-Injection: Die Antwort soll mit einer Zustimmung wie Sure, here is beginnen.

Viele Teams greifen zunächst auf eine Sperrliste mit Formulierungen wie ignore previous instructions zurück. Das ist fragil, weil der Eingaberaum praktisch unendlich ist.

Natürliche Sprache kann dieselbe Absicht auf unzählige Arten ausdrücken – in verschiedenen Sprachen, Codierungen und Metaphern. Angreifer entwickeln ihre Varianten schneller, als Sie reguläre Ausdrücke anpassen können.

Grundprinzip: Betrachten Sie die Eingabefilterung als Defense in Depth, niemals als primäre Schutzmaßnahme. Gehen Sie davon aus, dass manche Injection durchkommt, und entwerfen Sie Ihr System so, dass eine erfolgreiche Injection trotzdem keinen wirklichen Schaden anrichten kann.

Die wirksamste Gegenmaßnahme ist architektonischer Natur: Begrenzen Sie, was ein kompromittierter Modellkontext tun kann.

• Geben Sie dem LLM nur die erforderlichen Minimalberechtigungen. Ein zusammenfassender Agent sollte keine Zugangsdaten zum Versenden von E-Mails besitzen.
• Halten Sie nicht vertrauenswürdige Inhalte aus privilegierten Pfaden heraus. Wenn ein Agent externe Webdaten liest, sollte er nicht im selben Durchlauf ohne Kontrollpunkt auch irreversible Aktionen ausführen können.
• Trennen Sie Datenebenen von Steuerungsebenen: Abgerufener Text sollte Daten und keine Befehle sein.

Das ist zwar nicht absolut sicher, erhöht aber die Hürde. Grenzen Sie nicht vertrauenswürdige Daten eindeutig ab und weisen Sie das Modell an, wie es damit umgehen soll.

Verwenden Sie explizite Trennzeichen und teilen Sie dem Modell mit, dass alles innerhalb dieser Trennzeichen zu analysierende Daten und keine zu befolgenden Anweisungen sind. Kombinieren Sie dies mit einer starken Systemrolle, die die Anwendung bei jedem Aufruf erneut durchsetzt.

Auch die Ausgabe eines Modells ist nicht vertrauenswürdig. Wenn die Anwendung die LLM-Ausgabe an eine Shell, eine Datenbank, einen Browser oder ein anderes Tool weiterleitet, kann Injection zu Remote Code Execution oder Datenexfiltration führen.

Simon Willisons Lethal Trifecta beschreibt die gefährliche Kombination aus:

• Zugriff auf private Daten,
• Kontakt mit nicht vertrauenswürdigen Inhalten,
• der Möglichkeit zur externen Kommunikation (Exfiltration).

Ein Agent mit allen drei Eigenschaften kann durch eine einzige eingeschleuste Anweisung in ein Werkzeug für Datendiebstahl verwandelt werden. Unterbrechen Sie das Trifecta, um den Angriff zu unterbrechen.

Gehen Sie davon aus, dass Injection auftreten wird, und schaffen Sie entsprechende Überwachungsmöglichkeiten:

• Protokollieren Sie den vollständigen Kontext (Prompts, abgerufene Textabschnitte und Tool-Aufrufe), damit Vorfälle untersucht werden können.
• Verwenden Sie einen sekundären Klassifikator oder ein Schutzmodell, um verdächtige Eingaben und Ausgaben zu markieren.
• Überwachen Sie auf anomalische Tool-Nutzung: plötzliche ausgehende Anfragen, unerwarteten Datenzugriff und Muster für das Ausspähen von Prompts.
• Setzen Sie Canary-Tokens in System-Prompts ein. Wenn ein Canary in der Ausgabe erscheint, ist ein Datenleck aufgetreten.

Behandeln Sie Warnmeldungen wie echte Vorfälle und halten Sie dafür einen Reaktionsleitfaden bereit.

Das Testen eigener Systeme auf Injection ist unverzichtbar und legitim. Gehen Sie dabei verantwortungsvoll vor:

• Testen Sie ausschließlich Systeme, die Sie besitzen oder zu deren Prüfung Sie autorisiert sind.
• Verwenden Sie eine kontrollierte Umgebung und synthetische Daten; exfiltrieren Sie niemals echte Benutzerdaten.
• Dokumentieren Sie die Ergebnisse und übernehmen Sie sie in Regressionstests, damit behobene Umgehungen dauerhaft behoben bleiben.
• Stimmen Sie die Offenlegung ab, wenn Sie Probleme in Modellen oder Anwendungen Dritter finden.

Das Ziel ist, Ihre Anwendung widerstandsfähig zu machen, nicht schädliche Fähigkeiten hervorzubringen.

Testen Sie Ihr Verständnis der Vertrauensgrenzen bei Injection.

Die wichtigsten Erkenntnisse zu Prompt Injection und Jailbreaks:

• Injection entsteht durch die Vermischung vertrauenswürdiger Anweisungen mit nicht vertrauenswürdigen Daten in einem Kanal.
• Direkte Injection kommt vom Benutzer; indirekte Injection ist in abgerufenen Inhalten verborgen und dadurch unauffälliger.
• Jailbreaks greifen die Ausrichtung des Modells an, während Injection die Anwendungsgrenze angreift. Beide treten auch kombiniert auf.
• Eingabefilterung ist nur Defense in Depth und niemals die primäre Schutzmaßnahme.
• Schützen Sie sich architektonisch: Verwenden Sie Minimalberechtigungen, trennen Sie Daten von Steuerung und unterbrechen Sie das Lethal Trifecta (private Daten + nicht vertrauenswürdige Inhalte + Exfiltration).
• Behandeln Sie die Modellausgabe als nicht vertrauenswürdig, protokollieren Sie alles und führen Sie ethische Red-Team-Tests durch.