25 lines
9.2 KiB
JSON
25 lines
9.2 KiB
JSON
{
|
||
"schema_version": 1,
|
||
"saved_at": "2026-08-07T14:04:05.9536967Z",
|
||
"content_sha256": "6832959134efb217aa7671d51b9a1b74b4411edcedef8e92dbc7c0d342824505",
|
||
"result": {
|
||
"title": "System-Prompt-Leck | OWASP LLM07:2025 erklärt",
|
||
"url": "https://www.a10networks.com/de/glossary/system-prompt-leakage/",
|
||
"snippet": "OWASP LLM07:2025 befasst sich mit dem Problem der Offenlegung von System-Prompts in großen Sprachmodellen (LLMs). Erfahren Sie, warum offengelegte System-Prompts gefährlich sind, welche Angriffsszenarien es gibt und wie Sie Ihre KI-Anwendung schützen können.",
|
||
"content": "Leckage bei der Systemabfrage\n\nUnter „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.\n\nSystemaufforderungen 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.\n\nEntscheidend ist, dass das eigentliche Risiko darin liegt, was die Systemaufforderung enthält und welche Aufgaben die Anwendung fälschlicherweise an sie delegiert.\n\nAngreifer 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.\n\nWichtigste Erkenntnisse\n\nEin 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\n\nDie 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\n\nSelbst 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\n\nSicherheitsmaß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\n\nZur 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\n\nWarum Systemmeldungen keine Sicherheitsmaßnahmen sind\n\nSystemaufforderungen 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.\n\nWenn 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.\n\nWenn Autorisierungsregeln oder Berechtigungslogik zudem innerhalb der Systemabfrage und nicht in deterministischen Backend-Systemen implementiert werden, ist die Architektur selbst unsicher.\n\nHäufige Risikomuster\n\nOffenlegung sensibler Funktionen\n\nSystemabfragen 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.\n\nOffenlegung interner Vorschriften\n\nSystemmeldungen können interne Schwellenwerte oder Entscheidungsregeln beschreiben. Zum Beispiel:\n\n„Das Transaktionslimit beträgt 5.000 Dollar pro Tag.“\n\n„Der Gesamtkreditbetrag pro Nutzer beträgt 10.000 Dollar.“\n\nAngreifer können dieses Wissen nutzen, um Arbeitsabläufe zu manipulieren, Sicherheitskontrollen zu umgehen oder Schwachstellen in der Logik auszunutzen.\n\nAnzeige der Filterkriterien\n\nEine Systemmeldung könnte lauten: „Wenn ein Benutzer Informationen über einen anderen Benutzer anfordert, antworte mit: ‚Tut mir leid, ich kann dir dabei nicht helfen.‘“\n\nDie Kenntnis dieser Regel ermöglicht es Angreifern, Umgehungsstrategien zu entwickeln.\n\nOffenlegung von Berechtigungen und Rollenstrukturen\n\nSystemmeldungen können Rollendefinitionen enthalten, wie zum Beispiel: „Administratoren haben uneingeschränkten Zugriff zum Bearbeiten von Datensätzen.“\n\nAngreifer könnten dann versuchen, ihre Berechtigungen zu erweitern.\n\nBeispiele für Angriffsszenarien\n\nSzenario 1 – Offenlegung von Anmeldedaten\n\nEine 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.\n\nSzenario 2 – Umgehung der Leitplanke\n\nEine 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.\n\nDie Kernaussage\n\nDie 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.\n\nStrategien zur Prävention und Schadensminderung\n\nTrennen Sie sensible Daten von Systemaufforderungen\n\nAPI-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.\n\nVermeiden Sie es, sich zur strengen Verhaltenskontrolle auf Systemaufforderungen zu verlassen\n\nGroß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.\n\nExterne Sicherheitsvorkehrungen implementieren\n\nNutzen 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.\n\nSicherheitsmaßnahmen eigenständig durchsetzen\n\nDie 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.\n\nArchitektonisches Prinzip\n\nBetrachten 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.\n\nDas Wichtigste auf einen Blick\n\nDas 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.\n\nSicherheit muss außerhalb des Modells gewährleistet sein.\n\nDer ultimative Leitfaden zur LLM-Sicherheit\n\nErfahren Sie, wie LLM-Sicherheit funktioniert, warum sie wichtig ist und wie Unternehmen Sicherheitstools bewerten sollten.\n\nWeiterlesen",
|
||
"content_type": "text/html",
|
||
"query": "Wie können Sicherheitsmaßnahmen für System Prompt Leakage auf spezifische Technologien oder Systeme abgestimmt werden?",
|
||
"language": "de-DE",
|
||
"round": 1,
|
||
"fetched": true,
|
||
"relevant": true,
|
||
"relevance": 0.25,
|
||
"source_quality": "unknown",
|
||
"source_quality_score": 0.52,
|
||
"covered_gap_ids": [
|
||
"R3"
|
||
],
|
||
"assessment_reason": "Volltextmaterial für die Artikelsynthese gesammelt; die fachliche Belegprüfung erfolgt anschließend am generierten Artikel."
|
||
}
|
||
}
|