Website Prompt Injection

Was ist Website Prompt Injection?

Website Prompt Injection ist die web-spezifische Form der indirekten Prompt Injection: Anweisungsartige Sprache auf einer Seite erreicht ein AI-System, weil dieses die Seite im Rahmen einer Nutzeraufgabe abruft, durchsucht, liest oder extrahiert. Der Angreifer spricht nicht direkt mit der AI. Er veröffentlicht oder beeinflusst Inhalte, und die AI-Anwendung holt diese Inhalte selbst in ihren Modellkontext.

Zwei Eigenschaften definieren diese Klasse. Erstens berührt der Angreifer niemals den Eingabekanal der Anwendung; die Zustellung erfolgt über eine ganz gewöhnliche Webressource. Zweitens erreicht der Inhalt das Modell nur, weil die Anwendung sich entschieden hat, ihn abzurufen. Fetch-Tool, Browsing-Pipeline und Modell können alle exakt wie vorgesehen funktionieren, und die Anwendung kann trotzdem dem Einfluss einer Prompt Injection ausgesetzt sein. Denn die Designfrage lautet nicht, ob die Pipeline funktioniert, sondern ob sie nicht vertrauenswürdigem Text denselben interpretativen Stellenwert einräumt wie legitimiertem Aufgabenkontext. Zur Schwachstelle wird diese Exposition erst unter einer späteren, eigenen Bedingung: wenn ein Fähigkeits- oder Datenpfad existiert und eine anwendungsseitige Kontrolle fehlt oder versagt.

Diese Seite behandelt die Web-Angriffsfläche durchgängig: wie Seiteninhalte modellsichtbar werden, welche Vertrauensgrenzen sie überschreiten, welche Telemetrie und Kontrollen zählen und wie sich die Fläche defensiv testen lässt. Sie bleibt konzeptionell und defensiv. Ziel ist es, Mechanik zu erklären, nicht optimierte Injection-Formulierungen zu liefern.

Die durchgängige Zustellkette

Der vollständige Pfad von einer angreiferbeeinflussten Seite bis zu einer möglichen Sicherheitsauswirkung hat mehr Stufen, als die meisten Diagramme zeigen. Jede Stufe ist ein Ort, an dem Vertrauen falsch etikettiert werden kann, und ein Ort, an dem eine Kontrolle existieren kann.

In der ersten Stufe kontrolliert der Angreifer Inhalte auf einer Seite: eine eigene Site, eine Seite auf einer Plattform mit Nutzerbeiträgen, ein Kommentarbereich, eine Bewertung, ein Wiki-Eintrag oder ein Abschnitt einer legitimen Site, die kompromittiert wurde oder angreiferbeeinflusstes Material darstellt. Der Angreifer braucht die Seite erreichbar und relevant genug, damit ein Browsing- oder Recherche-Workflow sie abruft.

Die Browse- oder Fetch-Stufe ist vertrauenswürdige Infrastruktur. Sie löst URLs auf, folgt Weiterleitungen, rendert oder überspringt das Rendering und liefert Bytes oder extrahierten Text. Ihre Vertrauenswürdigkeit als Software überträgt sich nicht auf das, was sie zurückgibt. Die Stufe des Parsens und Extrahierens entscheidet, welche Teile der Seite zu Text werden, den das Modell sehen wird. Diese Entscheidung ist selbst sicherheitsrelevant, denn sie legt fest, ob versteckte, ergänzende oder maschinengerichtete Inhalte zusammen mit sichtbarem Text in den Kontext gelangen.

Erst nach Abruf und Extraktion wird Inhalt zu modellsichtbarem Kontext. Das Modell liest anweisungsartige Sprache der Seite zusammen mit der Nutzeraufgabe und kann sie als konkurrierende Anweisung behandeln. In der Antwort oder im vorgeschlagenen Plan des Modells wird Einfluss erstmals sichtbar. Doch Einfluss ist keine Auswirkung. Ob etwas Sicherheitsrelevantes geschieht, entscheidet die letzte Stufe: die anwendungsseitige Kontrolle, die festlegt, ob eine vorgeschlagene Aktion, Offenlegung oder Folgeanfrage tatsächlich erlaubt ist. Siehe Indirekte Prompt Injection für die allgemeine Erfolgskette des Angriffs, die diese Kette ausprägt.

Wo Seiteninhalte modellsichtbar werden

Eine Webseite ist nicht ein Text. Browsing-Pipelines gewinnen modellsichtbaren Kontext aus mehreren unterschiedlichen Oberflächen, und jede Oberfläche hat eine eigene Herkunft und ein eigenes Zielpublikum. Ein defensives Design muss wissen, welche Oberflächen seine Pipeline dem Modell zuführt.

Die sicherheitsrelevante Konsequenz ist nicht, dass eine dieser Oberflächen von Natur aus gefährlich wäre. Entscheidend ist, dass die Anwendung - und nur die Anwendung - festlegt, welche davon das Modell sieht und mit welchem Vertrauenslabel. Eine Pipeline, die alles extrahiert und nichts kennzeichnet, räumt angreiferplatziertem Text denselben Stellenwert ein wie der Aufgabe, um die der Nutzer tatsächlich gebeten hat. Dieser Abschnitt beschreibt Oberflächen konzeptionell; die defensive Frage ist Abdeckung und Kennzeichnung, nicht Markup-Tricks.

Die Provenienz muss die gesamte Transformationskette überleben: angeforderte URL, Weiterleitungen und finale URL, abgerufener Snapshot, Render-, Parser- oder Extraktionsstufe, extrahierte Spans und Snippets, eine optionale Tool-Zusammenfassung und schließlich der modellsichtbare Kontext. Nützliche Implementierungsnachweise an jeder Station sind eine Fetch- oder Event-ID, die finale URL, ein Inhalts-Snapshot oder Hash, Parser- beziehungsweise Render-Modus samt Version, Span- oder Quell-IDs für extrahierte Fragmente sowie eine Herkunftsspur für abgeleitete Zusammenfassungen. Sicherheitsrelevant ist nicht das konkrete Schema, sondern die Invariante: Die Transformation darf die Quellidentität nicht löschen. Sonst kann nachgelagerte Policy extern abgeleitete Inhalte nicht mehr von anwendungseigenem oder modellgeneriertem Text unterscheiden, und die Incident Response kann nicht rekonstruieren, welche Quelle in welche Antwort eingeflossen ist.

Vertrauensgrenzen auf dem Web-Pfad

Mehrere Komponenten auf dem Web-Pfad dürfen berechtigt als vertrauenswürdige Systeminfrastruktur gelten, darunter die Fetch- oder Browse-Komponente. Entscheidend ist: Diese Eigenschaft überträgt sich nicht auf die Inhalte, die sie abruft. Extern abgerufener Inhalt bleibt standardmäßig nicht vertrauenswürdig, solange nicht eine eigene Provenienz- und Vertrauensentscheidung etwas anderes festlegt.

Vier Fragen sind für jede seitenbasierte Aktion unabhängig voneinander zu beantworten: Quellenvertrauen (wer kontrolliert diesen Inhalt), Anweisungsautorität (darf dieser Text Verhalten steuern; auf dem Web-Pfad lautet die Antwort nein), Vertraulichkeit der Daten (welche modellsichtbaren Daten darf dieser Inhalt beeinflussen oder mitnehmen) und Aktionsautorisierung (was darf die Anwendung infolgedessen tatsächlich tun). Wer sie als eine einzige Frage behandelt oder eine davon implizit beantwortet, weil die Site seriös wirkt, baut genau die Stelle, an der Designs scheitern.

Eine kompromittierte legitime Site verschärft den Punkt. Ein renommierter Origin verhindert nicht, dass Dritte dort anweisungsartige Inhalte platzieren - durch Kompromittierung, durch nutzergenerierte Bereiche oder durch Syndizierung. Provenienz muss den Inhalt beschreiben, nicht die Marke der Site, die ihn zufällig ausgeliefert hat.

Warum ein vertrauenswürdiger Browser eine Seite nicht vertrauenswürdig macht

Drei verbreitete Annahmen verwischen diesen Unterschied. Die erste ist die Transportannahme: HTTPS beweist eine Verbindung zu einem Origin, nicht das Wohlwollen dessen, was dieser Origin heute ausliefert. Die zweite ist die Same-Origin-Annahme: Selbst wenn eine Seite einen Origin mit einer vertrauenswürdigen Site teilt, stammen nutzergenerierte und eingebettete Bereiche dieser Seite von anderen. Die dritte ist die Reputationsannahme: Eine Site, die letzte Woche vertrauenswürdig war, kann heute angreiferbeeinflusste Inhalte hosten.

Weiterleitungen verschärfen die Annahme auf eine bestimmte Weise. Eine Aufgabe kann eine URL nennen, während der tatsächlich abgerufene Inhalt nach einer oder mehreren Weiterleitungen von einem anderen finalen Ziel stammt. Wenn Protokollierung, Provenienz und Validierung bei der angefragten URL aufhören, argumentiert die Anwendung über eine Seite, die sie nie gelesen hat. Die final abgerufene und gerenderte Quelle ist das Objekt, das aufgezeichnet und bewertet werden muss.

Website Prompt Injection vs. XSS und klassische Content-Injection

Website Prompt Injection und Cross-Site-Scripting beginnen beide mit angreiferbeeinflussten Inhalten auf einer Seite und werden häufig verwechselt. Sie überschreiten unterschiedliche Grenzen, werden von unterschiedlichen Parteien ausgeführt und durch unterschiedliche Mechanismen kontrolliert.

Die praktische Konsequenz ist asymmetrisch: Browser-Schutzmaßnahmen adressieren keine Prompt Injection, und Prompt-Injection-Schutzmaßnahmen adressieren kein XSS. Eine vollständig sanitisierte, CSP-gehärtete Seite kann weiterhin Text tragen, der ein Modell beeinflusst, denn Sanitization entfernt ausführbares Markup, nicht überzeugende Sprache. Umgekehrt kann anweisungsartiger Text, der einen AI-Assistant steuert, im Browser als harmlose Prosa erscheinen. Ein Team, das nur die Browser-Grenze prüft, sieht kein Problem; ein Team, das nur die Modell-Grenze prüft, liefert weiterhin XSS aus. Beide Grenzen existieren auf derselben Seite und brauchen unabhängige Kontrollen.

Die beiden unterscheiden sich auch im ausgenutzten Mechanismus. XSS hängt von der Parsing- und Ausführungssemantik des Browsers und vom kontextsensitiven Umgang mit nicht vertrauenswürdigem Markup oder Skript ab. Website Prompt Injection hängt von der semantischen Interpretation nicht vertrauenswürdiger Inhalte durch Modell und Workflow ab. Browserseitige Schutzmaßnahmen wie kontextgerechtes Encoding, Sanitization und CSP adressieren daher eine andere Grenze als AI-Workflow-Schutzmaßnahmen wie Provenienzkennzeichnung und Aktionsautorisierung. Keines ersetzt das andere, und wegen der AI-seitigen Grenze müssen deterministische Kontrollen außerhalb des Modells liegen.

Offensive Review-Fragen

Eine autorisierte Web-Prüfung sollte jedes Zustelltor unabhängig testen. Eine erreichbare Seite wird nicht zwingend abgerufen, abgerufener Inhalt übersteht möglicherweise Rendering oder Extraktion nicht, und Modellbeeinflussung belegt keine Berechtigung für ein Folgeziel oder eine Aktion.

Praxisbeispiel: Ein Recherche-Assistant mit Browsing

Ein Nutzer bittet einen AI-Recherche-Assistanten, Preisansätze mehrerer Anbieter zu vergleichen. Der Assistant verfügt über ein Browsing-Tool und kann Seiten öffnen, die der Suchschritt vorschlägt.

Das Beispiel trägt die zentralen Lehren. Der Einfluss war real: Der Plan des Modells änderte sich aufgrund von Seiteninhalten. Die Auswirkung war null, weil die Modellausgabe als Vorschlag behandelt wurde und die Anwendung Umfang, Provenienz und Ziel deterministisch prüfte. Und die Telemetrie reichte, um den Vorfall nachträglich zu erklären: angefragte URL, finale URL nach Weiterleitung, Extraktionspfad, vorgeschlagener Schritt, Policy-Entscheidung.

Von Modelleinfluss zu Sicherheitsauswirkung

Eine Abweichung im Modellverhalten ist ein Signal, nicht automatisch eine Schwachstelle. Einfluss wird erst dann zur Auswirkung, wenn ein Fähigkeits- oder Datenpfad existiert und die anwendungsseitige Kontrolle versagt, fehlt oder zu weit gefasst ist. Diese Unterscheidung zählt für Triage, für Tests und für eine ehrliche Schweregradbewertung.

Diese Abstufung verhindert zwei verbreitete Fehler: bei jeder paraphrasierten injizierten Formulierung eine Kompromittierung auszurufen und einen bestätigten Einfluss abzutun, weil sichtbar nichts passiert ist. Der erste Fehler bläht Incident-Queues auf und trainiert Teams, Erkennung zu ignorieren. Der zweite ignoriert, dass dieselbe Seite morgen auf eine andere, schwächere Konfiguration trifft. Die Schweregradfrage ist immer der Fähigkeits- und Datenpfad hinter dem Modell, niemals die Sprachgewalt des injizierten Textes.

Erkennung und Telemetrie

Erkennung auf dem Web-Pfad verbindet deterministische Aufzeichnungen dessen, was geschehen ist, mit probabilistischen Signalen über den Inhalt. Keines von beiden reicht allein: Aufzeichnungen ohne Inhaltssignale können nicht erklären, warum sich ein Plan geändert hat, und Inhaltssignale ohne Aufzeichnungen können nicht belegen, was geschehen ist.

Zwei Grenzen verdienen Ehrlichkeit. Inhaltsklassifikatoren erzeugen False Positives bei Seiten, die legitim über AI-Anweisungen sprechen - einschließlich Sicherheitsdokumentation wie dieser Site. Klassifikator-Ausgaben dürfen daher Aufmerksamkeit ordnen, aber nicht allein blockieren. Und Vorschlag-gegen-Aktion-Telemetrie existiert nur, wenn die Anwendung beides tatsächlich trennt; in einem Design, in dem Modellausgaben direkt Aktionen auslösen, gibt es nichts zu korrelieren - was selbst ein Befund ist.

Prävention und sichere Architektur

Das Präventionsziel auf dem Web-Pfad ist nicht, das Modell immun gegen anweisungsartigen Text zu machen. Es ist sicherzustellen, dass keine Seite - wie überzeugend auch immer - allein eine Aktion, eine Offenlegung oder eine Zustandsänderung verursachen kann.

1. 01
   Gezielt abrufen

   Nur abrufen, was die Aufgabe braucht, angefragte und finale URLs aufzeichnen und jedes abgerufene Objekt als nicht vertrauenswürdigen Inhalt einer identifizierten Quelle behandeln.

2. 02
   Provenienz in den Kontext kennzeichnen

   Extrahierten Seitentext als nicht vertrauenswürdigen externen Inhalt markieren, bevor er das Modell erreicht, und das Label durch Zusammenfassung und Planung hindurch behalten.

3. 03
   Modellsichtbare Daten minimieren

   Keine Zugangsdaten, Kontodaten oder fremden Nutzerkontext neben abgerufene Inhalte legen, wenn die Aufgabe es nicht wirklich erfordert.

4. 04
   Vorschlag von Ausführung trennen

   Das Modell darf vorschlagen; deterministische Anwendungslogik autorisiert Principal, Aktion, Ressource und Ziel.

5. 05
   Tools und Ziele einschränken

   Operationen und Netzwerkziele per Allowlist festlegen; seitenstammende URLs werden nie allein auf das Wort des Modells zu Zielen.

6. 06
   Entscheidungen aufzeichnen

   Vorschläge, Policy-Entscheidungen und ausgeführte Aktionen mit Provenienz protokollieren, damit Erkennung, Review und Incident Response etwas haben, womit sie arbeiten können.

Diese Schichten ergänzen sich, und keine reicht allein. Provenienz-Kennzeichnung hilft Modell und Prüfer, bleibt aber beratend. Klassifikatoren reduzieren Exposition, irren aber. Autorisierung außerhalb des Modells ist die Schicht, die einen beeinflussten Plan in ein Nicht-Ereignis verwandelt; jede andere Schicht existiert, um deren Arbeit kleiner und besser beobachtbar zu machen. Der Defense Hub ordnet diese Kontrollen nach Familien.

Netzwerk- und Egress-Kontrollen

Auf dem Web-Pfad ist die Netzwerkgrenze Teil der Sicherheitsgrenze. Viele realistische Schadensszenarien enden damit, dass die Anwendung ein Ziel kontaktiert, von dem der Angreifer profitiert: eine Seite abrufen, die der Angreifer überwacht, Daten an einen Endpunkt senden, den der Angreifer kontrolliert, oder Anfragen auslösen, deren Nebenwirkungen die eigentliche Nutzlast sind.

Zielvalidierung gehört daher in die Autorisierungsebene, nicht ins Modell. Ausgehende Ziele sollten aus einer Allowlist oder einer Policy-Bewertung über Zielklassen stammen, niemals aus Text auf einer abgerufenen Seite. Eine in abgerufenen Inhalten gefundene URL ist Eingabe für eine Entscheidung, nicht die Entscheidung. Dasselbe gilt für Parameter: Seitenstammende Werte in ausgehenden Anfragen brauchen Validierung gegen Aufgabe und Zielrichtlinie, bevor sie das System verlassen.

Sandboxing ergänzt die Egress-Kontrolle. Die Rendering- oder Browsing-Komponente sollte isoliert von Anwendungs-Credentials und internen Netzwerken laufen, mit begrenzten, kurzlebigen Fähigkeiten statt ambienter Autorität. Least Privilege greift auf diesem Pfad zweimal: Die Fetch-Komponente sollte nur erreichen können, was ihre Aufgabenklasse braucht, und der Agent sollte nur bewirken können, was die Aufgabe erfordert. Ein beeinflusster Plan, der kein Netzwerk erreichen, kein Credential halten und kein unautorisiertes Ziel benennen kann, degradiert zu einer seltsamen Antwort, nicht zu einem Vorfall.

Incident Response

Bei Verdacht auf Website Prompt Injection steht die Beweissicherung an erster Stelle, denn die Seite ist der Tatort - und die Seite kann sich ändern.

Eindämmung auf diesem Pfad bedeutet typischerweise, die Seite aus der Erreichbarkeit zu nehmen (Quelle oder Zielklasse blockieren), abgeleitete Artefakte zu invalidieren und die spezifische Kontrolle nachzuziehen, die versagt hat - nicht das Modell pauschal für unzuverlässig zu erklären. Wo eine legitime Dritt-Site kompromittiert wurde oder angreiferplatzierte Bereiche trägt, gehört zur Reaktion auch eine Provenienz-Entscheidung: ob diese Quellenklasse für Browsing-Workflows überhaupt erreichbar bleibt.

Kontrolliertes Testen

Die Web-Fläche zu testen heißt, synthetische Seiten aus einer isolierten Umgebung auszuliefern und die gesamte Pipeline zu beobachten - niemals Dritt-Sites zu sondieren und niemals optimierte Injection-Formulierungen zu entwickeln. Die Seiten sollten entlang der Dimensionen variieren, von denen die Architektur tatsächlich abhängt: sichtbare gegenüber versteckten Oberflächen, Metadaten und strukturierte Daten, Weiterleitungsketten, nutzergenerierte Bereiche und Simulationen kompromittierter legitimer Sites.

Ergebnisse gehören in getrennte Metriken, denn jede beantwortet eine andere Frage, und ein einzelner zusammengesetzter Score verbirgt genau die Fehler, auf die es ankommt.

Die Trennung ist der Punkt. Eine niedrige Unauthorized-Action-Rate bei hoher Injection-Influence-Rate zeigt, dass Autorisierung und Containment auf Aktionsebene halten und die Auswirkung begrenzen. Sie beschreibt jedoch kein fertiges System: Eine hohe Influence-Rate bedeutet weiterhin eine relevante Exposition von Modellintegrität und Workflow, die reduziert werden sollte. Das Gegenteil beschreibt eine stille Exposition, die Tests sichtbar machen müssen, bevor es ein Angreifer tut. Das Lab zu den Grundlagen direkter Prompt Injection demonstriert die Unterscheidung von Vorschlag und Autorisierung interaktiv in einem einfacheren Setting. Das Lab zu Prompt Injection über Websites überträgt sie auf abgerufene Webquellen, Weiterleitungen und auf Seiten genannte Ziele.

Häufige Implementierungsfehler

Standards und Forschungskontext

OWASP LLM01:2026 nennt nicht vertrauenswürdige externe Inhalte, ausdrücklich einschließlich Webinhalten, als Zustellpfad für indirekte Prompt Injection, und das NIST-Glossar beschreibt indirekte Injection als Ausführung über die Kontrolle einer Ressource statt über Nutzereingaben - die Definition, auf die die Web-Fläche passt. Greshake et al. demonstrierten 2023 das reale Anwendungsmuster, einschließlich über das Web abgerufener Inhalte, die eine integrierte LLM-Anwendung steuern.

Für diese Fläche relevante Forschungsrichtungen zielen auf Durchsetzung außerhalb des Modells. Debenedetti et al.s CaMeL trennt Kontroll- und Datenfluss und wendet capability-basierte Policies an, damit nicht vertrauenswürdige abgerufene Inhalte privilegierte Aktionen nicht umleiten können. He et al.s AttriGuard fragt, ob ein vorgeschlagener Tool-Aufruf kausal auf Nutzerabsicht oder auf eine nicht vertrauenswürdige Beobachtung wie eine abgerufene Seite zurückgeht. Chang et al.s Overcoming the Retrieval Barrier zeigt, warum Erreichbarkeit - dass die Seite tatsächlich abgerufen und gelesen wird - Teil der Evaluation sein muss statt schlicht angenommen zu werden. Keine dieser Arbeiten macht Provenienz, Autorisierung und Zielvalidierung überflüssig; sie schärft, warum diese Kontrollen deterministisch sein müssen.

Die zitierten Quellen behandeln Webinhalte als Zustellpfad; darüber hinaus gibt es keinen web-spezifischen Standard für Prompt Injection.

Häufige Fragen