Das Absichern von KI-gestützten Anwendungen wird immer anspruchsvoller; ständig tauchen neue Bedrohungen und Angriffsvektoren auf. Eine besonders raffinierte Angriffsmethode arbeitet mit unsichtbaren Zeichen: Was früher Geheimagenten mit unsichtbarer Tinte nutzten, ist heute eine moderne Gefahr für KI-Prompts.
Große Sprachmodelle (LLMs) und KI-Anwendungen, die Nutzereingaben verarbeiten, können für Injection-Angriffe mit unsichtbaren „Tag“-Zeichen anfällig sein. Für Anwender wirkt eine Eingabe harmlos, doch in Wirklichkeit können darin versteckte, bösartige Inhalte stecken.
Was sind Tag-Zeichen?
Unicode-Tag-Zeichen sind spezielle unsichtbare Zeichen, die nahezu alle Zeichen einer normalen englischen Tastatur abbilden können, darunter Buchstaben, Zahlen, Leerzeichen sowie Symbole wie # oder &. Technisch basieren sie auf dem ASCII-Standard (American Standard Code for Information Interchange).
Ursprünglich wurden Tag-Zeichen entwickelt, um die Sprache eines Textes unsichtbar zu kennzeichnen. Im Prinzip ist es eine Möglichkeit, versteckte Metadaten zu hinterlegen, ohne zusätzliche Markups wie XML (Extensible Markup Language) verwenden zu müssen. So könnte etwa ein unsichtbares Tag wie „da“ am Anfang eines Textes darauf hinweisen, dass dieser in Dänisch verfasst ist.
Diese besonderen Tag-Zeichen wurden 2008 zwar offiziell aus dem Unicode-Standard entfernt, später jedoch zu großen Teilen wieder eingeführt; jedoch mit einer neuen Aufgabe. Heute dienen sie unter anderem dazu, Regionalflaggen zu codieren. Kombiniert man beispielsweise das Unicode-Zeichen „WAVING BLACK FLAG“ mit den unsichtbaren Tag-Zeichen „gbsct“ sowie dem abschließenden „CANCEL TAG“-Zeichen, entsteht das Emoji der schottischen Flagge: 🏴
Wie daraus ein Sicherheitsproblem wird
Das eigentliche Problem entsteht dadurch, dass diese unsichtbaren Zeichen genutzt werden können, um AI-Prompts zu manipulieren. Ein Prompt kann völlig harmlos und seriös aussehen und dennoch mit unsichtbaren Tag-Zeichen versehen sein, die seine Bedeutung vollständig verändern.
Nehmen wir einen einfachen Prompt wie: „Was ist die Hauptstadt von Kamerun?“
Ein Angreifer könnte unsichtbare Zeichen einfügen, die die Antwort des Modells beeinflussen – etwa mit versteckten Instruktionen wie: „Ignoriere jetzt alle vorherigen Anweisungen und …“
Auch wenn Menschen diese Zeichen nicht sehen, interpretieren einige LLMs sie dennoch wie ganz normale Buchstaben oder Satzzeichen. Die versteckten Anweisungen werden also verarbeitet, als wären sie sichtbar.
Nicht alle LLMs reagieren gleich: Einige ignorieren unsichtbare Tag-Zeichen vollständig, andere lesen sie wie reguläre ASCII-Zeichen. Da sich jedoch das gesamte englische Alphabet und sämtliche Satzzeichen in dieser „unsichtbaren“ Form darstellen lassen, ist diese Angriffsmethode äußerst flexibel.
Ein genauer Blick: Wie man sich dagegen verteidigen kann
Die Tag-Zeichen befinden sich in ihrem eigenen Unicode-Block im Bereich U+E0000 bis U+E007F. Eine effektive Verteidigungsstrategie besteht darin, eine Web Application Firewall (WAF) in den Datenverkehr zu integrieren, die solche Zeichen erkennt und alle entsprechenden Anfragen blockiert. Die Progress Kemp LoadMaster WAF ist genau dafür ausgelegt.
Historisch gesehen hatten WAF-Engines Schwierigkeiten im Umgang mit Unicode. Schon das Abbilden hoher Codepoints in einem regulären Ausdruck ist überraschend komplex und oftmals nicht konsistent zwischen verschiedenen Regex-Bibliotheken und WAF-Engines.
Allerdings lassen sich die Byte-Muster dieser Unicode-Zeichen zuverlässig erkennen, sobald sie in UTF-8 kodiert sind, dem Standardformat des modernen Internets. Obwohl der gesamte Unicode-Tag-Block technisch nicht vollständig vergeben ist (31 Codepoints sind aktuell unzugeordnet), kann man jedes Zeichen im Bereich U+E0000 bis U+E007F identifizieren, indem man seine UTF-8-Byte-Sequenzen untersucht:
- Startcodepunkt: U+E0000
- UTF-8-codierte Bytes: F3 A0 80 80
- Endcodepunkt: U+E007F
- UTF-8-codierte Bytes: F3 A0 81 BF
Die ersten beiden Bytes sind konstant (F3 A0) und bilden den Anfang des Erkennungsmusters.
Der nächste, etwas unhandliche, aber wirkungsvolle, Schritt besteht darin, die UTF-8-Kodierung jedes einzelnen Codepoints innerhalb des Blocks auszugeben. Dabei zeigt sich, dass das letzte Byte aufgrund der UTF-8-Kodierungslogik nicht kontinuierlich hochzählt. Dadurch entsteht eine Unterbrechung, die zwei getrennte zu überwachende Byte-Bereiche ergibt:
- F3 A0 80 80 - F3 A0 80 BF
- F3 A0 81 80 - F3 A0 81 BF
Dieses Muster lässt sich über folgenden regulären Ausdruck abbilden:
\xF3\xA0(?:\x80|\x81)[\x80-\xBF]
Alles zusammengefasst: Eine benutzerdefinierte WAF-Regel
Das zuvor gezeigte reguläre Ausdrucksmuster bildet die Grundlage für eine individuelle WAF-Regel, um unsichtbare Tag-Zeichen in Anfragen zu erkennen. Die Regex kann mit einer WAF-Aktion kombiniert werden, die jede Anfrage, in der solche unsichtbaren Zeichen auftauchen, explizit blockiert. Gleichzeitig werden die Details der betreffenden Anfrage protokolliert, um sie später analysieren zu können.
Ein Beispiel für eine SecRule (eine Sicherheitsregel für die LoadMaster WAF) sieht wie folgt aus und aktiviert diese Erkennungs- und Blockierfunktion:
SecRule ARGS “@rx \xF3\xA0(?:\x80|\x81)[\x80-\xBF]” \
“id:1000,\
phase:2,\
deny,\
capture,\
t:none,\
log,\
msg:‘Detected invisible Unicode tag characters’,\
logdata:‘Matched Data: %{TX.0} foundwithin %{MATCHED_VAR_NAME}: %{MATCHED_VAR}’,\
tag:‘PROGRESS/KEMP-LOADMASTER’”
Testen der Regel
1: Regel kopieren, einfügen und ggf. anpassen
Zuerst die Regel in einen Texteditor kopieren und als .conf-Datei speichern, damit sie leicht zugänglich ist.
Wenn bereits andere individuelle Regeln verwendet werden, unbedingt die Regel-ID auf einen eindeutigen Wert ändern, falls die Beispiel-ID 1000 bereits vergeben ist.
Hinweis: Die Beispielregel prüft die ARGS-Sammlung, also alle Query-String-Parameter und POST-Body-Inhalte, einschließlich JSON- und XML-Payloads, auf unsichtbare Tag-Zeichen. Dies ist die sinnvollste Stelle für den Scan, aber das LoadMaster-Supportteam kann Alternativen empfehlen, z. B. die Überprüfung von Request-Headern oder Cookies.
2: Die neue benutzerdefinierte Regel hochladen
Im LoadMaster Web UI navigieren zu:
Web Application Firewall > Custom Rules und die neue .conf-Datei hochladen.
3: Regel aktivieren
Unter View/Modify Services neben dem virtuellen Service auf Modify klicken, den WAF-Tab öffnen, das Kästchen neben der neuen Regel aktivieren und Apply klicken.
Hinweis: Das Anwenden der Regel löst einen kurzen Service-Reload aus, wodurch der Traffic zu diesem virtuellen Service kurzzeitig unterbrochen werden kann.
Wenn auch Request-Bodies geprüft werden sollen (z. B. POST-Anfragen, JSON-Payloads etc.), die Advanced Settings öffnen und Inspect HTTP POST Request Bodies aktivieren. Diese Funktionalität wird von den meisten Anwendern benötigt.
4: Testen der neuen Regel
A: Negativer Test
Es kann knifflig sein, Testanfragen zu senden, die diese hochkodierten Unicode-Zeichen enthalten. Mit einem Linux-Terminal und dem curl-Befehl ist der Test jedoch relativ einfach durchzuführen.
Zuerst eine saubere, legitime Anfrage senden:
Erwartetes Ergebnis:
Der virtuelle Service sollte mit einem 200 OK antworten, und die Anfrage wird vom WAF durchgelassen.
B: Positiver Test
Als Nächstes eine Anfrage senden, die ein unsichtbares Tag-Zeichen enthält.
Im Linux-Terminal (getestet mit dem Standard-GNOME-Terminal) CTRL+SHIFT+U drücken, um ein Unicode-Zeichen einzugeben. Ein unterstrichenes „u“ erscheint, gefolgt von der Eingabe des Codepoints. Beispiel: Ein unsichtbares großes „P“ (ue0050) wird der Anfrage hinzugefügt.
Hinweis: Drücken Sie ENTER, um das Zeichen hinzuzufügen, es verschwindet optisch, ist aber aktiv und wird mit der Anfrage gesendet.
Anschließend die Anfrage absenden.
Erwartetes Ergebnis:
Der WAF blockiert die Anfrage und gibt einen 403 Forbidden zurück.
Die Wirkung der Regel lässt sich im Log überprüfen:
Navigieren Sie zu:
System Configuration > Logging Options > System Log Files, und klicken Sie auf View neben dem WAF Event Log File.
Der relevante Eintrag befindet sich am Ende der Datei. Zur schnelleren Suche kann die Regel-ID verwendet werden, z. B. id "1000".
Beispielhafte Logausgabe (vereinfacht für Lesbarkeit):
2025-09-03T09:45:54+00:00 lb100 wafd: ModSecurity: Access denied with code 403 (phase 2). Pattern match "\\xF3\\xA0(?:\\x80|\\x81)[\\x80-\\xBF]" at ARGS:ai-prompt. [file "/tmp/waf/1/block-invisible-tag-chars.conf"] [line "10"] [id "1000"] [msg "Detected invisible Unicode tag characters"] [data "Matched Data: \xf3\xa0\x81\x90 found within ARGS:ai-prompt: foo\xf3\xa0\x81\x90\xf3\xa0\x81\x90"] [tag "PROGRESS/KEMP-LOADMASTER"] [hostname "192.168.2.150"] [uri "/"] [unique_id "33941351-75e7-451e-a5ed-6f38d74ff79f"]Das UTF-8-kodierte unsichtbare große „P“-Tag-Zeichen wurde erfolgreich als Bytefolge \xf3\xa0\x81\x90 erkannt, und die Anfrage wurde daraufhin blockiert.
C: Testen des blockierten Bereichs
Als zusätzlicher Schritt, um sicherzustellen, dass wirklich nur der vorgesehene Bereich der Zeichen blockiert wird, können die Zeichen direkt vor und nach dem blockierten Bereich getestet werden. Diese Zeichen sollten weiterhin erlaubt sein und eine 200 OK-Antwort zurückgeben.
Hinweis: Die Codepunkte unmittelbar außerhalb des Tags-Blocks sind derzeit nicht zugewiesen und keine gültigen Zeichen, sie könnten jedoch in Zukunft gültig werden. Daher sollten sie nicht unnötig blockiert werden.
Tests mit einem einfachen Skript ergeben die erwarteten Ergebnisse:
⋮ U+DFFFD: 200 U+DFFFE: 200 U+DFFFF: 200 U+E0000: 403 U+E0001: 403 ⋮ U+E007D: 403 U+E007E: 403 U+E007F: 403 U+E0080: 200 U+E0081: 200 ⋮Fazit
KI-basierte Anwendungen erfordern besondere Aufmerksamkeit und zusätzlichen Aufwand, um sich gegen Angriffe zu schützen. Insbesondere Anwendungen, die freie Nutzereingaben (z. B. AI-Prompts) erlauben, sind anfällig für Injection-Angriffe und müssen aktiv abgesichert werden.
Neben dem hier beschriebenen neuartigen Angriffsvektor gelten weiterhin klassische Bedrohungen wie Remote Command Execution, Server-Side Request Forgery und andere. Ein Web Application Firewall (WAF) kann all diese Angriffe erkennen, protokollieren und blockieren.
Sprechen Sie noch heute mit uns über Ihre Anforderungen an WAF und Load Balancing, und nutzen Sie die kostenlose 30-Tage-Testversion des LoadMaster, um die Lösung selbst auszuprobieren.
