Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 2
Nach der allgemeinen Einführung in die Content Security Policy geht es nun um deren Anweisungen.
Die Anweisungen der CSP
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.
Ü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
Trackbacks
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 2.2014 - Angriffsziel Webbrowser
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 12.2014 - JavaScript und die Sicherheit
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"
Vorschau anzeigen
www.drweb.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.