Dipl.-Inform. Carsten Eilers

Außer der bereits vorgestellten Anweisung script-src für JavaScript-Ressourcen gibt es für viele weitere Ressourcen entsprechende Anweisungen:

connect-src

legt die Origins fest, zu denen Verbindungen über XMLHttpRequests, WebSockets und EventSource aufgebaut werden dürfen.

font-src

legt fest, von welchen Origins Web Fonts geladen werden dürfen. Für Googles Web Fonts lautet der Header zum Beispiel
Content-Security-Policy: font-src https://themes.googleusercontent.com

frame-src

legt fest, von welchen Origins Daten in Frames eingebettet werden dürfen. YouTube-Videos können zum Beispiel mit dem Header
Content-Security-Policy: frame-src https://youtube.com
eingebettet werden, während Seiten von anderen Origins nicht in Frames eingebunden werden können.

media-src

legt fest, von welchen Origins Video- und Audio-Dateien geladen werden dürfen. Beachten Sie die Feinheiten: Diese Anweisung ist für das Einbinden der reinen Multimedia-Dateien zuständig, wenn Sie einen Player wie zum Beispiel den von YouTube in einem Frame verwenden wollen, müssen Sie das Einbinden eines entsprechenden Frames erlauben, s.o..

object-src

legt fest, von welchen Origins Objekte für Plugins wie zum Beispiel Flash geladen werden dürfen. Analog wie im Fall der Multimedia-Daten gilt dies wieder nur für die reinen Objekte, soll zum Beispiel YouTubes Videoplayer als Frame eingebunden werden, muss das ggf. auch ausdrücklich erlaubt werden.

img-src

legt fest, von welchen Origins Bilder geladen werden dürfen, und

style-src

legt fest, von welchen Origins Stylesheets geladen werden dürfen.

Per Default offen wie ein Scheunentor

Per Default sind alle Anweisungen weit offen: Wenn eine Direktive nicht angegeben wird, hat dass die gleiche Wirkung als wäre sie mit einem Wildcard ("*") gesetzt worden. Lassen Sie zum Beispiel font-src weg, hat das die gleiche Wirkung als würden Sie den Header

Content-Security-Policy: font-src *

setzen: Fonts können von beliebigen Servern geladen werden.

Bei Bedarf kann dieses Defaultverhalten über die Anweisung default-src an die eigenen Sicherheitsbedürfnisse angepasst werden:

Content-Security-Policy: default-src https://guter-server.example

sorgt dafür, dass für alle nicht spezifizierten Direktiven nur Ressourcen von der Default-Quelle https://guter-server.example geladen werden können. Wurde also zum Beispiel wie im Beispiel in der Einführung lediglich script-src spezifiziert, können zum Beispiel Fonts (und alle weiteren Ressourcen, für die keine Direktive spezifiziert wurde) nur von https://guter-server.example geladen werden.

'Gibt es nicht' gibt es auch

Bisher ging es immer um die Frage, von welchen Origins Ressourcen geladen werden dürfen. Aber was ist, wenn man weiß, dass man bestimmte Ressourcen gar nicht braucht? Wenn Ihre Webanwendung zum Beispiel keine Plugins nutzt, können Sie durch die Angabe von

Content-Security-Policy: object-src 'none'

festlegen, dass generell keine Objekte geladen werden dürfen.

Nur eine Anweisung pro Type

Sie können so viele Anweisungen im Content-Security-Policy-Header verwenden, wie es für Ihre Anwendung nötig ist. Die verschiedenen Anweisungen werden dazu durch ein Semikolon (;) getrennt. Jeder Type darf aber nur einmal vorkommen und muss alle entsprechenden Ressourcen aufführen. Weitere Anweisungen des gleichen Types werden nämlich ignoriert.

Um also zum Beispiel das Laden von JavaScript-Dateien von den Servern https://server1.example und https://server2.example zu erlauben, müssen Sie die Anweisung

Content-Security-Policy: script-src https://server1.example https://server2.example

verwenden. Falls Sie den Header

Content-Security-Policy: script-src https://server1.example; script-src https://server2.example

senden, wird die zweite script-src-Anweisung vom Browser ignoriert, so dass nur Skripte von https://server1.example geladen werden dürfen.

Ein Beispiel

Nehmen wir mal an, eine Webanwendung nutzt folgende Ressourcen:

• Videos werden vom Server https://video.server.example geladen,
• alle anderen Ressourcen werden vom Content Delivery Network https://cdn.anwendung.example geladen, und
• es werden keine Frames oder Plugins verwendet

Damit ergibt sich der folgende CSP-Header (die Umbrüche dienen nur der besseren Lesbarkeit)

Content-Security-Policy: default-src https://cdn.anwendung.example; 
                         media-src https://video.server.example;
                         frame-src 'none'; 
                         object-src 'none'

Der Header dürfte selbsterklärend sein.

In der nächsten Folge werden unter anderem die Schlüsselwörter der CSP vorgestellt.

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