Vertrauensgrenzen zwischen Funktionen gezielt testen

Tests von Vertrauensgrenzen zwischen Funktionen prüfen, ob eine Fähigkeit, die in einem Teil einer Anwendung sicher ist, durch eine andere Funktion unsicher erreichbar wird. Beginnen Sie mit dem, was ein Angreifer kontrolliert. Verfolgen Sie jeden Übergang in einen Kontext mit höheren Rechten und testen Sie die Kombinationen, die ihn ermöglichen. Dass eine Funktion ihre eigenen Sicherheitsprüfungen besteht, liefert nur einen Teil der nötigen Nachweise.

Für ein kleines Sicherheitsteam zählt ein konkretes Ergebnis: eine kurze Matrix der Funktionszustände, eine Meldung über die dadurch erreichbare Fähigkeit und eine Nachprüfung aller bereitgestellten Varianten. Als Ausgangspunkt genügt ein geteiltes Artefakt samt den Komponenten, die dafür Nachrichten empfangen oder Inhalte darstellen.

Eine isolierte Vorschau schützt nicht vor einem zu vertrauensvollen Empfänger

In seinem Bericht vom 28. Oktober beschrieb Parameter eine Angriffskette in ChatGPT, die eine geteilte Unterhaltung, einen Graphen und eine HTML-Vorschau kombinierte. Den Forschern zufolge lud der Graph MathLive in die Hauptseite. Die Vorschau konnte daraufhin Nachrichten an einen Listener senden, der HTML für Tastaturlayouts annahm, ohne den Absender ausreichend zu prüfen. Dieser Darstellungspfad erzeugte einen Frame ohne Sandbox; ein zugelassener Endpunkt für Drittanbieterskripte ermöglichte die Umgehung der CSP.

Parameter demonstrierte über die angemeldete Sitzung Zugriff auf private Gesprächsdaten. Die zuverlässigste Reproduktion erforderte, den geteilten Inhalt zu öffnen und auf „Preview“ zu klicken. Außerdem berichtete Parameter von drei Reproduktionen, bei denen sich die Vorschau automatisch öffnete. Laut Parameter bestätigte OpenAI am 26. Oktober, dass beide Versionen des Web-Frontends die gemeldeten Nachrichten zurückwiesen.

Dies sind von den Forschern berichtete Ergebnisse, keine von uns durchgeführten Tests. Die Diskussion auf Hacker News liefert den Nachrichtenkontext. Die praktische Lehre lautet: Prüfen Sie, wie getrennte Funktionen Befugnisse weitergeben, einschließlich der Wege zum Veröffentlichen oder Teilen.

Diese Aufgabe unterscheidet sich von der Prüfung, ob bösartiger Text einen Agenten umlenken kann. Bei Prompt Injection im Abrufpfad eines Recruiting-Agenten geht es darum, wie abgerufene Inhalte einen Assistenten beeinflussen, der Werkzeuge nutzt. Ein Empfänger im Browser, der eine unbefugte Anweisung annimmt, kann auch versagen, ohne ein Modell zu beeinflussen. Ebenso ist die Aufgabe von der Mandantentrennung beim Anbieter zu unterscheiden. Dort geht es darum, ob die nachgelagerte Verarbeitung Kunden korrekt voneinander trennt.

Halten Sie fest, wo Daten zu Befugnissen werden

Eine Übersicht der Vertrauensgrenzen sollte sowohl die nicht vertrauenswürdige Eingabe als auch die privilegierte Operation benennen, die sie beeinflussen kann. „Die Vorschau läuft in einer Sandbox“ beschreibt eine Komponente. Die Aussage erklärt nicht, was die umgebende Anwendung tut, wenn diese Vorschau eine Nachricht sendet.

Beschreiben Sie den Ablauf in einfachen Worten:

1. Jemand außerhalb des Kontos des Opfers kontrolliert ein geteiltes Artefakt.
2. Beim Öffnen wird eine Komponente auf einer authentifizierten Seite geladen.
3. Eine andere Komponente nimmt eine Anweisung aus dem Artefakt entgegen.
4. Die Anweisung beeinflusst die Darstellung, eine Anfrage oder eine Kontoaktion.

Benennen Sie für jeden Übergang den Empfänger und den Grund, aus dem er die Eingabe annimmt. Prüft er einen exakten Origin? Ein bestimmtes Fenster? Einen Nachrichtentyp? Eine Autorisierungsentscheidung auf dem Server? Wenn lediglich das erwartete Nachrichtenformat geprüft wird, haben Sie eine Annahme gefunden, die Sie genauer untersuchen sollten.

Die MDN-Empfehlungen zu postMessage verlangen, die Identität des Absenders zu prüfen und empfangene Daten zu validieren. Beim Senden empfehlen sie außerdem einen exakten Ziel-Origin. Ein bekanntes Nachrichtenformat begründet keine Berechtigung, die Fähigkeiten des Empfängers zu nutzen.

Trennen Sie in der Übersicht die Befugnisse von Browser und Server. Ein Server kann eine Anfrage korrekt für den angemeldeten Nutzer autorisieren, während vom Angreifer kontrollierter Code die Möglichkeit erlangt hat, diese Anfrage zu senden. Die Untersuchung muss dann erklären, wie dieser Code in den authentifizierten Kontext gelangte.

Erstellen Sie eine kleine Matrix der Funktionskombinationen

Testen Sie die kleinste Zahl von Kombinationen, mit der sich eine veränderte Vertrauensgrenze nachweisen lässt. Beginnen Sie mit jeder Komponente einzeln und kombinieren Sie sie anschließend. Berücksichtigen Sie den Weg, über den eine andere Person das Artefakt tatsächlich öffnet.

Die folgende Matrix dient als Planungsbeispiel für eine Anwendung mit geteilten Vorschauen. Sie dokumentiert keine Tests an ChatGPT oder Kit.

Notieren Sie vor jedem Test das erwartete Verhalten. Zum Beispiel: „Das übergeordnete Fenster weist eine Einstellungsnachricht aus dieser Vorschau zurück, weil der Absender diese Einstellung nicht ändern darf.“ Ein gescheiterter Angriffsversuch allein ist mehrdeutig. Möglicherweise hat der Empfänger ihn zurückgewiesen; möglicherweise wurde der Empfänger gar nicht geladen.

Verwenden Sie autorisierte Testkonten und harmlose Markierungen. Legen Sie für die Untersuchung eines möglichen Zugriffs auf private Daten einen Testdatensatz mit einem unverwechselbaren synthetischen Wert an. Sie brauchen genügend Nachweise für den Grenzübertritt. Echte Nutzerdaten zu sammeln erhöht das Risiko, ohne die Erklärung zu verbessern.

Variieren Sie das zeitliche Verhalten bewusst, wenn Komponenten unabhängig voneinander initialisiert werden. Halten Sie fest, ob eine Aktion erst nach dem Laden einer anderen Funktion gelingt, ob Neuladen das Ergebnis verändert und ob die normale Oberfläche einen zusätzlichen Klick erfordert. Diese Voraussetzungen gehören in die Meldung: Sie beeinflussen die Reproduzierbarkeit und die Umstände, unter denen jemand auf das Problem stoßen kann.

Belegen Sie für die Sichtung eine Fähigkeit, nicht nur ein Meldungsfenster

Eine hilfreiche Meldung weist nach, was im betroffenen Kontext möglich wurde. Ein Screenshot eines Meldungsfensters kann zeigen, wo JavaScript ausgeführt wurde. Er beantwortet nicht, welche Daten oder Operationen diese Ausführung erreichen konnte.

Bereiten Sie die Meldung so auf, dass ein anderer Entwickler das Ergebnis ohne Vermutungen reproduzieren kann:

• Kontrolle des Angreifers: das Artefakt, Feld, die Datei oder Nachricht, die der Melder bereitstellen kann.
• Voraussetzungen beim Opfer: Kontozustand, Rolle, aktivierte Funktionen und erforderliche Interaktionen.
• Überschrittene Grenze: Absenderkontext, Empfänger und die vom Empfänger akzeptierte Operation.
• Minimale Reproduktion: genauer Aufrufpfad und Ablauf mit synthetischen Testdaten.
• Erwartetes und beobachtetes Verhalten: was hätte verweigert werden müssen und was stattdessen geschah.
• Nachgewiesene Auswirkungen: der konkret erreichte private Testdatensatz oder die eingeschränkte Aktion.
• Grenzen der Untersuchung: unzuverlässiges zeitliches Verhalten, ungetestete Rollen, nicht verfügbare Varianten und hypothetische Erweiterungen.

Trennen Sie einen nachgewiesenen Lesezugriff von einem vermuteten Schreibzugriff. Ruft der Nachweis einen privaten synthetischen Datensatz ab, benennen Sie diese Verletzung der Vertraulichkeit direkt. Scheint eine weitere Kontoaktion erreichbar, wurde aber nicht getestet, kennzeichnen Sie sie als Hypothese. Pauschale Formulierungen wie „vollständige Kontoübernahme“ ersetzen nicht die konkreten Nachweise, die das Team zur Bewertung des Umfangs braucht.

Lässt sich eine Meldung nicht reproduzieren, ermitteln Sie die fehlende Voraussetzung, bevor Sie sie verwerfen. Eine begleitende Funktion, eine andere Frontend-Version oder eine zweite Interaktion können den Unterschied erklären. Fragen Sie gezielt danach und ergänzen Sie die Matrix, damit die nächste Reproduktion vom selben Zustand ausgeht.

Prüfen Sie die Korrektur des Empfängers entlang des gesamten Pfads

Die Überprüfung einer Behebung sollte erklären, warum der ursprüngliche Grenzübertritt jetzt scheitert. Ein blockiertes nachgelagertes Skript kann eine bestimmte Demonstration verhindern, während unbefugte Nachrichten weiterhin die vertrauenswürdige Darstellung beeinflussen können.

Untersuchen Sie die Entscheidung des Empfängers und testen Sie den Pfad vom Artefakt aus erneut. Kann der nicht vertrauenswürdige Absender die Einstellung noch ändern? Gelangen seine Daten weiterhin in eine HTML-Ausgabestelle? Behalten dynamisch erzeugte Inhalte die vorgesehenen Einschränkungen? Welcher Schutzmechanismus weist die Operation zurück, und kann der Test diese Zurückweisung beobachten?

Die Hinweise zu Web Messaging im OWASP Web Security Testing Guide behandeln Origin-Prüfungen und den Umgang mit Eingaben. Auch Eingaben von einem erlaubten Origin müssen angemessen validiert werden. Betrachten Sie Origin, Fensteridentität, Nachrichtenstruktur und erlaubte Operation als getrennte Fragen.

Verwenden Sie für die Nachprüfung die ursprüngliche Matrix. Ergänzen Sie dann verwandte Varianten, die sich aus dem betroffenen Code ergeben. Dazu können ein anderer Freigabepfad, eine weitere Komponente mit demselben Empfänger oder ein älteres Frontend gehören, das weiterhin Anfragen bedient. Machen Sie nicht aus jeder Meldung ein unbegrenztes Audit. Folgen Sie dem gemeinsamen Mechanismus und dokumentieren Sie, wo die Prüfung endet.

Prüfen Sie auch das legitime Verhalten. Eine autorisierte Komponente sollte ihre vorgesehene Operation weiterhin ausführen können, nachdem der unbefugte Absender zurückgewiesen wurde. Sonst besteht eine Korrektur, die die Funktion vollständig abschaltet, womöglich den Sicherheitstest, unterbricht aber den benötigten Arbeitsablauf.

Trennen Sie Behebung und Überprüfung

Dokumentieren Sie die Behebung und die bestätigenden Nachweise als getrennte Schritte. Eine bereitgestellte Änderung belegt, dass jemand eine Korrektur ausgeliefert hat. Die Überprüfung belegt, was erneut getestet wurde, in welcher Version und mit welchem Ergebnis.

Kits Sicherheitsworkflow hat getrennte Meldungsstatus für „Behoben“ und „Behebung verifiziert“. Das gibt dem Team einen Ort, um die Übergabe nachzuverfolgen. Es führt weder die Browser-Testmatrix aus noch beweist es, dass eine Grenze hält. Die Meldung braucht weiterhin die Reproduktion, Versionsangaben und Nachweise der Nachprüfung.

Beginnen Sie diese Woche mit einem öffentlichen oder teilbaren Artefakt. Listen Sie die privilegierten Komponenten auf, die es kontaktieren kann. Wählen Sie einen Empfänger, der Zustände ändert, und testen Sie das Artefakt allein sowie zusammen mit der Funktion, die diesen Empfänger lädt. Das Ergebnis sollte zeigen, wo Berechtigungen geprüft werden, und dem nächsten Entwickler genügend Nachweise liefern, um dieselbe Grenze zu überprüfen.