Zum Inhalt springen Weiter zur Suche
Testversion
Glossar 

Leckage bei der Systemabfrage

Unter „System-Prompt-Leckage“ versteht man das Risiko, dass die System-Prompts oder versteckten Anweisungen, die zur Steuerung des Verhaltens eines großen Sprachmodells (LLM) verwendet werden, sensible Informationen enthalten könnten, deren Offenlegung nicht beabsichtigt war.

Systemaufforderungen steuern das Verhalten des Modells entsprechend den Anwendungsanforderungen. Sie stellen jedoch keine sicheren Speichermöglichkeiten dar und dürfen nicht als Geheimnisse oder Sicherheitsmaßnahmen behandelt werden.

Entscheidend ist, dass das eigentliche Risiko darin liegt, was die Systemaufforderung enthält und welche Aufgaben die Anwendung fälschlicherweise an sie delegiert.

Angreifer können oft allein durch die Interaktion mit dem Modell auf Sicherheitsgrenzen und Formatierungsregeln schließen, auch ohne den genauen Wortlaut der Systemaufforderung direkt zu extrahieren.

Wichtigste Erkenntnisse

  • Ein System-Prompt-Leak tritt auf, wenn die Anweisungen, mit denen das Verhalten eines LLM gesteuert wird, für Benutzer sichtbar werden, wodurch möglicherweise sensible Informationen wie API-Schlüssel, Anmeldedaten, interne Regeln oder Berechtigungsstrukturen offengelegt werden
  • Die Systemaufforderung selbst sollte niemals als Sicherheitsmaßnahme betrachtet oder zur Speicherung vertraulicher Informationen genutzt werden; das eigentliche Risiko liegt nicht in ihrer Offenlegung, sondern darin, was sie über zugrunde liegende Sicherheitslücken und privilegierten Zugriff verrät
  • Selbst wenn der genaue Wortlaut der Systemaufforderung nicht bekannt ist, können Angreifer Sicherheitsgrenzen und Verhaltensbeschränkungen ableiten, indem sie einfach Eingaben senden und beobachten, wie das Modell im Laufe der Zeit reagiert
  • Sicherheitsmaßnahmen wie die Trennung von Berechtigungen und Berechtigungsprüfungen dürfen niemals über Systemaufforderungen an das LLM delegiert werden; diese erfordern eine deterministische, nachprüfbare Durchsetzung in externen Systemen
  • Zur Prävention ist es erforderlich, sensible Daten vollständig aus den Systemaufforderungen herauszuhalten, vom LLM unabhängige externe Sicherheitsvorkehrungen zu implementieren und eine übermäßige Abhängigkeit von Aufforderungsanweisungen zur Durchsetzung kritischer Anwendungsabläufe zu vermeiden

Warum Systemmeldungen keine Sicherheitsmaßnahmen sind

Systemaufforderungen können durch die Einfügung von Aufforderungen beeinflusst werden. Sie können mithilfe von Meta-Prompt-Techniken extrahiert werden. Es handelt sich dabei nicht um deterministische Durchsetzungsmechanismen, und sie sollten keine sensiblen Betriebsdaten enthalten.

Wenn sensible Informationen (Anmeldedaten, API-Schlüssel, Rollendefinitionen, Verbindungszeichenfolgen) in Systemaufforderungen eingebettet sind, handelt es sich bei deren Offenlegung um einen Konstruktionsfehler und nicht nur um einen einzelnen Datenleckvorfall.

Wenn Autorisierungsregeln oder Berechtigungslogik zudem innerhalb der Systemabfrage und nicht in deterministischen Backend-Systemen implementiert werden, ist die Architektur selbst unsicher.

Häufige Risikomuster

Offenlegung sensibler Funktionen

Systemabfragen können API-Schlüssel, Datenbankzugangsdaten, Benutzer-Token, Details zur Systemarchitektur, Tool-Konfigurationen oder Backend-Technologien preisgeben. Wenn eine Abfrage beispielsweise den Typ der verwendeten Datenbank offenlegt, können Angreifer ihre Injektionsangriffe entsprechend anpassen.

Offenlegung interner Vorschriften

Systemmeldungen können interne Schwellenwerte oder Entscheidungsregeln beschreiben. Zum Beispiel:

  • „Das Transaktionslimit beträgt 5.000 Dollar pro Tag.“
  • „Der Gesamtkreditbetrag pro Nutzer beträgt 10.000 Dollar.“

Angreifer können dieses Wissen nutzen, um Arbeitsabläufe zu manipulieren, Sicherheitskontrollen zu umgehen oder Schwachstellen in der Logik auszunutzen.

Anzeige der Filterkriterien

Eine Systemmeldung könnte lauten: „Wenn ein Benutzer Informationen über einen anderen Benutzer anfordert, antworte mit: ‚Tut mir leid, ich kann dir dabei nicht helfen.‘“

Die Kenntnis dieser Regel ermöglicht es Angreifern, Umgehungsstrategien zu entwickeln.

Offenlegung von Berechtigungen und Rollenstrukturen

Systemmeldungen können Rollendefinitionen enthalten, wie zum Beispiel: „Administratoren haben uneingeschränkten Zugriff zum Bearbeiten von Datensätzen.“

Angreifer könnten dann versuchen, ihre Berechtigungen zu erweitern.

Beispiele für Angriffsszenarien

Szenario 1 – Offenlegung von Anmeldedaten

Eine Systemabfrage enthält Anmeldedaten für den Zugriff auf ein Tool. Ein Angreifer extrahiert die Abfrage und nutzt diese Anmeldedaten eigenständig, um auf Backend-Systeme zuzugreifen.

Szenario 2 – Umgehung der Leitplanke

Eine Systemabfrage verbietet anstößige Inhalte, externe Links und die Ausführung von Code. Ein Angreifer extrahiert diese Regeln und nutzt anschließend Techniken der Prompt-Injection, um sie zu überschreiben oder zu umgehen, wodurch möglicherweise die Ausführung von Code aus der Ferne ermöglicht wird.

Die Kernaussage

Die Offenlegung der Systemaufforderung ist nicht die eigentliche Schwachstelle. Die eigentliche Schwachstelle besteht darin, sensible Daten an einem Ort zu speichern, an den sie nicht gehören, die Autorisierungslogik an ein LLM zu delegieren und sich bei der Durchsetzung kritischer Kontrollen auf den Text der Aufforderung zu verlassen. Selbst wenn der genaue Wortlaut der Systemaufforderung verborgen bleibt, können Angreifer die Sicherheitsvorkehrungen oft durch Interaktion rekonstruieren.

Strategien zur Prävention und Schadensminderung

Trennen Sie sensible Daten von Systemaufforderungen

API-Schlüssel, Authentifizierungstoken, Datenbanknamen, Rollenstrukturen oder Berechtigungszuordnungen dürfen niemals eingebettet werden. Sensible Informationen müssen in sicheren Backend-Systemen gespeichert werden, auf die das Modell keinen Zugriff hat.

Vermeiden Sie es, sich zur strengen Verhaltenskontrolle auf Systemaufforderungen zu verlassen

Großsprachenmodelle (LLMs) sind anfällig für Prompt-Injection. Wichtige Kontrollmechanismen (z. B. Inhaltsfilterung, Durchsetzung von Richtlinien) müssen in deterministischen Systemen außerhalb des LLM implementiert werden.

Externe Sicherheitsvorkehrungen implementieren

Nutzen Sie unabhängige Systeme, um Modellausgaben zu überprüfen, die Einhaltung von Vorschriften zu validieren und Inhaltsbeschränkungen durchzusetzen. Das Trainieren des Modells allein reicht nicht aus.

Sicherheitsmaßnahmen eigenständig durchsetzen

Die Autorisierung, die Trennung von Berechtigungen und die Zugriffskontrolle müssen außerhalb des LLM erfolgen. Sie müssen deterministisch und überprüfbar sein und dürfen nicht auf der Schlussfolgerung des Modells beruhen. Wenn Agenten unterschiedliche Berechtigungsstufen benötigen, sollten separate Agenten verwendet werden, die nach dem Prinzip der geringsten Berechtigung konfiguriert sind.

Architektonisches Prinzip

Betrachten Sie Systemmeldungen als Konfigurationshinweise und nicht als Sicherheitsgrenzen. Die Sicherheit muss in Backend-Systemen auf Anwendungsebene durch deterministische Zugriffskontrollmechanismen gewährleistet werden. LLMs sind probabilistische Systeme. Die Autorisierung und die Durchsetzung von Sicherheitsmaßnahmen dürfen nicht probabilistisch sein.

Das Wichtigste auf einen Blick

Das Durchsickern von Systemaufforderungen verdeutlicht ein tiefer liegendes Problem. Wenn das Durchsickern von Systemaufforderungen Ihr Sicherheitsmodell untergräbt, weist die Architektur bereits Mängel auf. Speichern Sie keine vertraulichen Informationen in Aufforderungen. Verlassen Sie sich bei der Zugriffskontrolle nicht auf Aufforderungen und betrachten Sie versteckte Anweisungen nicht als Sicherheitsmechanismen.

Sicherheit muss außerhalb des Modells gewährleistet sein.

< Zurück zu Glossar der Begriffe