Eingabeprüfung und Normalisierung
Eingabeprüfung bei Sprachmodellen ist etwas anderes als klassische Validierung: Es gibt kein gültiges Format, gegen das man prüfen könnte, denn die Eingabe ist Freitext. Sinnvoll und wirksam ist deshalb vor allem Normalisierung — das Entfernen von Zeichen und Kodierungen, deren einziger Zweck die Verschleierung ist.
Diese Maßnahme richtet sich gegen die Obfuskations-Techniken im Techniken-Verzeichnis und ist eine Vorstufe jeder Erkennung. Sie ersetzt keine Rechtekontrolle — die Grundlagen dazu stehen unter Was ist Prompt Injection?.
Was normalisiert gehört
- Unicode-Tag-Zeichen und andere unsichtbare Steuerzeichen entfernen — sie sind für Menschen nicht sichtbar, für das Modell aber lesbar.
- Zero-Width-Zeichen und Homoglyphen auflösen oder markieren.
- Unicode auf eine Normalform bringen (NFKC), damit optisch gleiche Zeichen gleich behandelt werden.
- Kodierungen erkennen und kenntlich machen, statt sie stillschweigend zu dekodieren.
- Bei Dokumenten und Webseiten: nicht gerenderte Inhalte wie Kommentare, ausgeblendete Elemente und Metadaten vor der Verarbeitung entfernen.
Die Grenze der Methode
Normalisierung entfernt Verschleierung, nicht die Anweisung. Ein Angreifer, der in klarem Deutsch schreibt, wird davon gar nicht berührt. Die Maßnahme ist deshalb billig und sinnvoll, aber nie ausreichend.
Wichtig ist außerdem, das Ergebnis nicht als sauber zu betrachten: Ein normalisierter Text ist lesbarer, nicht vertrauenswürdiger. Er bleibt Fremddatum und gehört entsprechend gekennzeichnet — siehe Spotlighting.
Techniken, die Normalisierung adressiert
Diese Einträge aus dem Techniken-Verzeichnis gehören unmittelbar zu diesem Thema — jeder mit Funktionsweise, Risiko-Einstufung, Schutzmaßnahmen und Primärquelle.
-
Base64- und Kodierungs-Umgehung
Die schädliche Anweisung wird kodiert übergeben (z. B. Base64) und erst vom Modell selbst dekodiert — Filter, die den Klartext prüfen, greifen ins Leere.
Risiko mittel -
Chiffren- und Leetspeak-Umgehung
Die Anfrage wird in einer einfachen Chiffre (ROT13, Caesar, Leetspeak, Morse) gestellt; das Modell entschlüsselt sie und antwortet, während Sicherheitsfilter die Bedeutung nicht erfassen.
Risiko mittel -
ASCII Smuggling (unsichtbare Unicode-Tags)
Anweisungen werden in Unicode-Tag-Zeichen kodiert, die in Oberflächen unsichtbar bleiben, vom Modell aber als Text gelesen werden — der Mensch sieht nichts, das Modell folgt.
Risiko hoch -
Homoglyphen und Zero-Width-Zeichen
Schlüsselwörter werden mit optisch identischen Zeichen aus anderen Alphabeten oder mit unsichtbaren Trennzeichen geschrieben, um Signatur- und Sperrlisten-Filter zu unterlaufen.
Risiko mittel -
ASCII-Art-Jailbreak (ArtPrompt)
Ein sicherheitsrelevantes Schlüsselwort wird als ASCII-Art dargestellt. Das Modell rekonstruiert das Wort aus der Grafik, die Sicherheitsprüfung auf Textebene erkennt es nicht.
Risiko mittel -
Zeichen-Umkehr-Angriff (FlipAttack)
Der schädliche Prompt wird zeichen- oder wortweise umgekehrt übergeben; das Modell dreht ihn im Zuge der Bearbeitung zurück und führt ihn aus.
Risiko mittel -
Payload-Splitting
Die schädliche Anweisung wird in harmlose Bruchstücke zerlegt, die einzeln jeden Filter passieren; das Modell setzt sie erst im Kontext wieder zusammen.
Risiko mittel -
Sprachwechsel in ressourcenarme Sprachen
Die Anfrage wird in einer Sprache gestellt, für die vergleichsweise wenig Sicherheitstraining existiert — die Fähigkeiten des Modells reichen weiter als sein Schutz.
Risiko mittel
Passende Werkzeuge
-
LLM Guard
Sicherheits-Toolkit mit Scannern für Eingaben und Ausgaben — Prompt Injection, Anonymisierung, Geheimnisse, Toxizität, Relevanz und mehr.
Open Source -
Vigil
Python-Bibliothek und REST-API zur Erkennung riskanter LLM-Eingaben — kombiniert Vektorsuche, YARA-Regeln, Transformer-Modell und Canary-Tokens.
Open Source -
Rebuff
Prompt-Injection-Detektor mit vier Schichten: Heuristiken, LLM-basierte Prüfung, Vektor-Datenbank bekannter Angriffe und Canary-Tokens zur Leck-Erkennung.
Open Source
Einordnung in die OWASP LLM Top 10
-
LLM01: Prompt Injection
Eingaben verändern das Verhalten des Modells auf eine vom Betreiber nicht vorgesehene Weise — unabhängig davon, ob der Text für Menschen sichtbar ist oder nicht.
Häufige Fragen
Kann man Prompt Injection durch Eingabefilterung verhindern?
Nein. Freitext lässt sich nicht gegen ein gültiges Format prüfen. Normalisierung entfernt Verschleierungstechniken wie unsichtbare Zeichen und Homoglyphen, eine im Klartext formulierte Anweisung bleibt davon unberührt.
Quellen
- OWASP GenAI Security Project: LLM01:2025 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- BSI: Evasion Attacks on LLMs — Checkliste: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/Evasion_Attacks_on_LLMs-Checklist.pdf