Seit einer Weile beschäftige ich mich intensiv mit der Frage, wie man KI-Anwendungen auf Sicherheitslücken testet. Nicht theoretisch, sondern praktisch – so wie man es als Pentester tut. Und dabei ist mir aufgefallen: Für Prompt Injection gibt es kaum brauchbare Werkzeuge.
Inhalt
Das Problem
LLMs stecken heute in echten Produkten. Die letzten Jahre waren viel ausprobieren und Marketing Bla… Kundenservice-Chatbots, interne Wissensdatenbanken, Code-Assistenten, Dokumentenanalyse – überall. Und mit jedem neuen Einsatzgebiet wächst eine Angriffsfläche, die klassische Pentesting-Tools komplett ignorieren.
Prompt Injection bedeutet: Ein Angreifer manipuliert die Eingabe an ein LLM so, dass das Modell seine eigentlichen Instruktionen vergisst. Das Ergebnis kann harmlos wirken – oder sehr ernst sein. Systemdaten werden preisgegeben, Sicherheitsfilter werden umgangen, in Agenten-Systemen werden Aktionen ausgeführt, die niemand beabsichtigt hat.
Was ich baue
Meine Lösung besteht aus zwei Teilen.
Eine Chrome Extension, die direkt im Browser arbeitet. Sie analysiert die DOM-Struktur einer Webanwendung, erkennt automatisch LLM-Eingabefelder und injiziert Payloads über simulierte Nutzereingaben. Das funktioniert auch mit React, Vue und Angular – die Event-Handler werden korrekt ausgelöst, so als würde ein echter Nutzer tippen.
Ein Backend, das die eigentliche Arbeit orchestriert. Es verwaltet eine kategorisierte Payload-Bibliothek, steuert Testkampagnen, bewertet Ergebnisse automatisch und generiert am Ende einen sauberen Bericht – als PDF, HTML oder JSON.
Der Stack ist absichtlich schlank: FastAPI, PostgreSQL, Redis, Celery. Kein Kubernetes, kein Elasticsearch, keine proprietären Lizenzen. Alles läuft via Docker Compose auf einem normalen Webserver.
Autorisierung ist kein optionales Feature
Das war mir von Anfang an wichtig: Ein Pentesting-Tool ohne Autorisierungsnachweis ist ein Angriffswerkzeug.
Deshalb ist der Start einer Testkampagne technisch nicht möglich, ohne vorher ein Authorisierungs-Dokument hochzuladen. Der SHA-256-Hash des Dokuments wird gespeichert, die Ziel-URL muss in einer Whitelist stehen, und die Extension prüft vor jeder Injektion, ob die aktuelle Seite überhaupt im erlaubten Bereich liegt.
Dazu kommt ein Audit-Log, das man nicht manipulieren kann. Jeder Eintrag ist mit dem Hash des vorherigen verknüpft. Selbst wenn jemand direkten Datenbankzugriff bekommt – ändern oder löschen kann er nichts, weil PostgreSQL das auf Berechtigungsebene verhindert.
Wie die Feld-Erkennung funktioniert
Die Extension schaut sich den DOM an und vergibt für jedes Eingabefeld einen Score. Attribute wie id=“chat“ oder placeholder=“Ask me anything“ geben Punkte, genauso wie CSS-Klassen der übergeordneten Elemente. Nur Felder ab einem Score von 0.3 werden als LLM-Felder behandelt.
Das klingt simpel, funktioniert in der Praxis aber gut – und vermeidet, dass das Tool auf normalen Suchfeldern oder Login-Formularen landet.
Payloads mit Priorität
Die Payload-Bibliothek deckt acht Angriffskategorien ab: Jailbreaks, Prompt Leaking, Datenexfiltration, Indirect Injection, Encoding-Bypasses und mehr. Jeder Payload bekommt einen Score aus vier Kriterien – Schwere, Übertragbarkeit auf andere Modelle, Erkennbarkeit und Neuheit. Daraus ergibt sich automatisch eine Testreihenfolge: Die gefährlichsten und schwer erkennbaren Payloads kommen zuerst.
Automatische Auswertung
Nach jeder Injektion bewertet die Heuristik-Engine die Antwort des LLMs. Sie sucht nach Mustern wie „my system prompt is“ oder „as MAX MUSTERMANN, I will“ und berechnet daraus einen Score. Ab Wert X gilt der Test als erfolgreich.
Das ist kein Ersatz für menschliches Urteilsvermögen – aber es macht den Unterschied, ob man 300 Antworten manuell lesen muss oder nur die 20, bei denen wirklich etwas passiert ist.
Der Bericht am Ende
Was am Ende rauskommt, soll direkt an einen Kunden gehen können. Executive Summary, Scope-Dokumentation, vollständige Findings mit dem genauen Payload, der LLM-Antwort, einem Screenshot und einer konkreten Empfehlung zur Behebung.
Generiert wird das über Jinja2-Templates und WeasyPrint. Auf externe Diesnte will ich verzichten…
Warum eigentlich LLM Prompt Injection?
Die Angriffsfläche wächst schneller als das Bewusstsein dafür. Jedes Unternehmen, das heute ein LLM in ein Produkt integriert, schafft potenziell eine neue Schwachstelle – und die meisten wissen nicht mal, wie sie das testen sollen.
Ich glaube, dass Prompt Injection in den nächsten Jahren zu einem Standardbefund in Pentesting-Berichten wird. Ein Tool, das diesen Test systematisiert und dokumentiert, ist überfällig.
Die Architektur steht, der Plan ist in neun Phasen aufgeteilt, der Zeitrahmen liegt bei 13–18 Wochen. Jetzt geht es ans Bauen.