wao.io und CSP

Reading Time: 4 minutes

In den letzten Wochen haben wir uns intensiver mit Content Security Policy (im Folgenden kurz CSP) und ihren möglichen Auswirkungen auf wao.io beschäftigt.

Was ist CSP?

Webbrowser laden eine ganze Menge Ressourcen (HTML, Bilder, Stylesheets, Scripts, …). Meistens tun sie das, weil der Entwickler der Webinhalte es so wollte. Häufig kommen noch andere Ressourcen dazu, über die der Entwickler keine direkte Kontrolle hat (z.B. Werbung). Manchmal ist aber auch Schadcode im Spiel, der von irgendwo eingeschleust wird. Hier kann CSP helfen.

CSP ist ein Mechanismus, mit dem Web-Entwickler z.B. kontrollieren können, welche Ressourcen ein Browser laden und ausführen soll. Oder wohin er AJAX-Verbindungen öffnen darf. Oder was er in Frames laden, wohin er Formulardaten verschicken, welche Arten von Plugins er einbetten darf. Und wohin er melden soll, wenn eine Aktion nicht den erlaubten Kriterien entspricht.

Die CSP-Spezifikation definiert z.B. ein HTTP-Response-Headerfeld Content-Security-Policy, in dem sogenannte Direktiven aufgelistet sind, die sich u.a. auf bestimmte Typen von Web-Ressourcen (Bilder, Scripts, Styles, Fonts, Medien etc.) beziehen. Der Wert dieser Direktiven ist eine Liste von z.B. Protokollen, Host-Namen, ganzen URLs oder bestimmten Keywords.

Einige Beispiele:

Hiermit wird der Browser angewiesen, nur externe Scripts, die mit http oder https referenziert sind, auszuführen. Die Ausführung von Inline-Scripts ist untersagt.

Das lässt sich einfach auf andere Typen ausweiten:

Die default-src-Direktive gilt für alle Ressource-Typen, wenn keine spezifischere Direktive angegeben ist. Mit ihr kann man eine Basis schaffen, die durch speziellere Direktiven verfeinert werden kann.

Grundsätzlich sind nur Ressourcen erlaubt, die von der Origin des aktuellen HTML-Dokuments geladen werden ('self'), zusätzlich aber auch Scripts von https://my.cdn.com.

Mit einer sogenannten hash-source kann man auch Inline-Scripts erlauben:

Alle Inline-Scripts, auf deren Inhalt keine hash-source passt, werden nicht ausgeführt. Fügt also z.B. ein Script, das nicht unter der Kontrolle des Autors ist, ein Inline-Script ins Dokument ein, wird das vom Browser nicht ausgeführt, weil es nicht explizit durch die CSP erlaubt ist.

In der ersten Stufe von CSP (Level 1) gab es diese spezifischen Ausnahmen noch nicht. Inline-Scripts oder -Styles konnten nur komplett mit 'unsafe-inline' erlaubt werden:

Will man auch Browser bedienen, die spezifische Ausnahmen nicht unterstützen, ist es ratsam, beides zu mischen:

CSP-Level-1-Browser erlauben damit alle Inline-Scripts. Browser, die Level 2 und höher unterstützen, ignorieren 'unsafe-inline', wenn eine spezifische Ausnahme angegeben ist.

Will man sich über Verstöße informieren lassen, fügt man eine report-uri-Direktive hinzu:

Der Browser schickt dann die Information zu jedem einzelnen Verstoß als JSON, in Firefox z.B.:

Man kann auch den Browser anweisen, nur Verstöße zu melden, aber ansonsten keine Blockierungsmaßnahmen durchzuführen. Dazu verwendet man das HTTP-Response-Headerfeld Content-Security-Policy-Report-Only:

Es ist ratsam, eine CSP erst einmal mit Content-Security-Policy-Report-Only auszuprobieren, bevor man sie mit Content-Security-Policy „scharf stellt“.

CSP ist also ein mächtiges Werkzeug, mit dem der Web-Entwickler relativ genau angeben kann, welche Ressourcen erlaubt und damit auch welche nicht erlaubt sein sollen.

CSP Auswirkungen auf wao.io

Weil durch verschiedene wao.io-Features Ressourcen einer Website verändert oder hinzugefügt werden, könnte es also vorkommen, dass bei bestimmen CSP-Einstellungen diese Features nicht mehr richtig funktionieren.

Im Folgenden wird beschrieben, welche CSP-Direktiven Einfluss auf wao-io-Features haben.

Bilder

Die Direktive img-src bestimmt, welche Bilder vom Browser geladen werden dürfen.

Betroffene Features: Image Delaying, Inlining

Hier werden data-URIs benutzt, um entweder das per http(s)-URI referenzierte Bild zu „inlinen“ oder zunächst einen Platzhalter zu referenzieren, bevor später diese Referenz gegen die eigentliche ausgetauscht wird.

Problem: Wenn in der CSP-Direktive img-src kein data: angegeben ist, werden data-URIs vom Browser nicht erlaubt. Die Features können so nicht funktionieren.

Lösung: Durch die Konfigurations-Option Allow Modification of Content Security Policy im Zusammenhang mit Image Delaying wird data: für die CSP-Direktive img-src hinzugefügt.

Die betroffenen Features werden nicht angewendet, wenn data: nicht im Wert der CSP-Direktive img-src gelistet ist.

Scripts und Styles

Die Direktive script-src bestimmt, welche Scripts vom Browser geladen bzw. ausgeführt werden dürfen (script-Element oder EventHandler-Attribute wie onsubmit).

Betroffene Features: Analytics, Image Delaying, Inlining, JavaScript Minifying (ggfs. Rewrite HTTP URLs to HTTPS)

Hier werden entweder script-Elemente mit Inhalt hergestellt oder der Inhalt von bestehenden verändert.

Die Direktive style-src bestimmt, welche Stile vom Browser geladen bzw. angewendet werden dürfen (Stylesheet-link-Elemente, style-Elemente und -Attribute).

Betroffene Features: Image Delaying, Inlining, CSS Minifying (ggfs. Rewrite HTTP URLs to HTTPS)

Hier werden entweder style-Elemente mit Inhalt hergestellt oder der Inhalt von bestehenden verändert.

Problem: script– bzw. style-Elemente mit Inhalt müssen in der CSP-Direktive script-src bzw. style-src entweder allgemein (script-src 'unsafe-inline') oder spezifisch durch eine nonce-source (z.B. style-src 'nonce-12fe8748ab54') oder ihr Inhalt konkret durch eine hash-source (z.B. script-src 'sha256-0446TkDOBAfOA02/3TWIC55LZPIgjmNIBMDg+duOdrQ=') erlaubt werden. Manche Features fügen neue script– bzw. style-Elemente ein, die bisher nicht durch die entsprechende CSP-Direktive erlaubt sind. Andere verändern bestehene möglicherweise durch hash-source geschützte Elementinhalte.

Lösung: Wenn in der relevanten CSP-Direktive bereits eine hash-source oder nonce-source gelistet ist, fügen wir für jedes neu einzufügende style– oder script-Element mit Inhalt eine passende hash-source hinzu. Andernfalls wird eine hash-source zusammen mit 'unsafe-inline' nur hinzugefügt, wenn die Konfigurations-Option Allow Modification of Content Security Policy eingeschaltet ist. Das Hinzufügen von 'unsafe-inline' dient der Abwärtskompatibilität für Browser, die nur CSP Level 1 unterstützen. Das sorgt aber in solchen Browsern auch dafür, dass alle Inline-Scripts und -Styles erlaubt sind, was ggfs. eine zu große Sicherheitslücke darstellt. Daher die zusätzliche Konfigurations-Option. Trifft auch das nicht zu, wird das neue Element nicht eingefügt: Features funktionieren dann nicht in ihrer vollen Ausprägung.

Die Minifizierung von Inhalten von script– und style-Elementen wird unterbunden, wenn in der relevanten CSP-Direktive eine hash-source vorkommt.

Das „Inlinen“ von CSS oder JavaScript wird unterbunden, wenn die jeweilige CSP-Direktive keine beliebigen Inline-Inhalte erlaubt.

Fazit

Sollen durch CSP geschützte Web-Ressourcen durch wao.io-Features verändert werden, ist einiger Aufwand nötig, damit diese Veränderungen auch durchgeführt werden können. Aber mit den getroffenen Maßnahmen ist es uns gelungen, wao.io-Features in vielen Fällen trotz restriktiver CSP-Direktiven anzuwenden. Wir haben darauf geachtet, die Eingriffe in die CSP so klein wie möglich zu halten, um die Sicherheit der Website nicht unnötig zu gefährden.

Leave a Comment

Your email address will not be published.