Mit CSP legst du nun fest, welche dynamische Ressourcen geladen werden dürfen und verhinderst somit solche Angriffe.
Früher oder später kommt jeder mit Content Security Policy oder kurz CSP in Kontakt. Du hast dir erfolgreich deinen Blog / Service erstellt, alles ist online und die letzten Feinheiten sind eingestellt und eingerichtet.
Eines fehlt dir aber noch: ein wenig Kommunikation und Interaktion mit deinen Besuchern. Du denkst dir, Twitter oder Disqus wäre toll. In QUIQQER ist Disqus für deinen Blog schnell eingerichtet. Häckchen rein, um deine Blogkommentare zu aktivieren und … tja, nichts passiert.
Als tüchtiger und findiger Entwickler machst du deine Browser-Konsole auf und findest eine Menge sehr merkwürdiger Fehler. Das muss nicht einmal mit Disqus passieren; mit Twitter und allen externen Services, welche JavaScript oder andere Inhalt nachladen, passiert das auch.
Das liegt daran, dass QUIQQER in seinem Header CSP nutzt und generell dem Browser sagt, dass alle externen Inhalte nicht geladen werden sollen.
Content Security Policy (CSP) kurz erklärt
Content Security Policy wird verwendet, um Cross-Site-Scripting oder Angriffe mit deiner Webseite auf deine Besucher zu verhindern. Mit CSP legst du nun fest, welche dynamische Ressourcen geladen werden dürfen und verhinderst somit solche Angriffe.
Gehen wir einmal von folgender Situation aus. Dein Blog besitzt eine Kommentarfunktion und ist mittlerweile eine gut besuchte Seite. Da die Kommentare deiner Seite direkt auf der Seite angezeigt werden, bietet diese auch immer eine Möglichkeit unerwünschte Inhalte einzuschleusen.
Kommentiert nun ein Besucher, nennen wir ihn Blackbeard, einen deiner Blogartikel und schafft es, HTML Code in diesen Kommentar zu bekommen, kann er somit jegliche andere Inhalte nachladen.
Es reicht schon, wenn er einen JavaScript Code mit in den Kommentar packt, welcher dann eine Datei nachlädt, welche wiederum anderen Code ausführt.
Zum Beispiel sowas hier:
Natürlich gibt es noch weitere Szenarien, sei es dass Blackbeard deinen lieblings Service hackt und darüber andere Inhalte lädt. Dinge wie automatische Tweets auf deiner Seite, Pinterest Boards von anderen Benutzern oder irgendwelche Services wie Facebook und Co. können missbraucht werden, um weitere Inhalte nachzuladen.
Hier kommt nun die Content Security Policy ins Spiel. Mit der Content Security Policy sagst du dem Browser *Nur Inhalte von bestimmten Seiten sind erlaubt*.
Sagen wir, du lässt *.twitter.com als erlaubte Richtlinie zu, heißt, dass der Browser jeden Inhalt von *.twitter.com laden und ausführen darf (z.B. JavaScript oder iFrames). Wenn über Twitter nun Inhalte von *.blackbeard.com nachgeladen werden sollten, werden diese unterdrückt..
Content Security Policy in QUIQQER einstellen.
In der Administration von QUIQQER sind die CSP Einstellungen zu finden unter:
Einstellungen -> QUIQQER -> System -> Inhaltsschutzrichtlinie
Unter Content Security Policy (CSP) kannst du nun verschiedene Richtlinien anlegen und auch bestehende Richtlinien einsehen oder editieren.
Die standard Einstellungen legen fest, dass Ressourcen von der eigenen Domain erlaubt sind. D.h. alle Ressourcen von deiner Homepage, die auch von dir kommen.
Das ganze kann etwas kryptisch aussehen, wenn aber bekannt ist, was die ganzen Abkürzungen, Werte und Richtlinien bedeuten, ist es schnell eingerichtet.
Content Security Policy Richtlinien
Damit du auch das ganze einstellen kannst, ist es gut zu wissen welche Richtlinien es gibt und was diese bedeuten. Die folgende Zusammenstellung hilft dir ein wenig.
default-src
Ist die standard Richtlinie zum Laden von Inhalten wie JavaScript, Bilder, CSS, Schriftarten, AJAX-Anfragen (XMLHTTPRequest), iFrames oder HTML5 Inhalte.
script-src
Definiert erlaubte JavaScript-Quellen.
style-src
Definiert erlaubte CSS-Quellen.
img-src
Definiert erlaubte Bild-Quellen
connect-src
Definiert erlaubte XMLHTTPRequest-, WebSocket-, oder EventSource-Quellen. Wenn der Browser eine nicht erlaubte Quelle aufruft, ahmt er einen 400 HTTP Status nach.
font-src
Definiert erlaubte Schriftarten-Quellen
object-src
Definiert erlaubte Objekt-Quellen. Objekte sind in diesem Fall <object>, <embed> oder <applet>.
media-src
Definiert erlaubte Audio- und Video-Quellen. Zum Beispiel HTML5 <audio> und <video> Elemente.
frame-src
Definiert erlaubte Frame-Quellen (<iframe>, <frame>). Nutze lieber child-src, da frame-src veraltet ist.
report-uri
Weist den Browser an, einen Bericht über Richtlinien-Fehler an diese URI zu senden.
child-src
Definiert erlaubte Frame-Quellen.
form-action
Definiert erlaubte Quellen, welche mit dem HTML Element <form> genutzt werden können.
Content Security Richtlinien Werte (Values)
Alle Richtlinien, welche mit -src enden, unterstützen größtenteils die gleichen Angaben.
* = Wildcard. Erlaubt jede URL
‘none’ = Verhindert das Laden von allen Quellen.
‘self’ = Lässt nur Quellen von der Ursprungsadresse zu. D.h also nur von deiner Domain (Host, Port und Schema müssen gleich sein).
‘unsafe-inline’ = Ermöglicht die Verwendung von Inline-Quell-Elementen wie style Attribute, onclick- oder <script> Tags (abhängig vom Kontext der Quelle, auf die es angewendet wird) und javascript: URIs
‘unsave-eval’ = Ermöglicht unsichere dynamische Code Interpretation (Ausführung) wie JavaScript
‘nonce-’ = Ermöglicht es, <style> und <script> auszuführen, wenn das nonce Attribut das gleiche ist wie im Header (dies ist für spätere Versionen von QUIQQER angedacht).
‘sha256-’ = Gleiches Vorgehen wie ‘nonce-’ nur mit einem sha256 Hash.
data: = Erlaubt Quellen via data Schema (z.B. base64 codierte Bilder)
subdomain.domain.com = Erlaubt Quellen von einer spezifischen Domain (Hier subdomain.domain.com)
*.domain.com = Erlaubt das Laden von Ressourcen von allen Subdomains der Domain domain.com.
https://domain.com = Erlaubt das Laden von Ressourcen nur von der Quelle domain.com und nur über https
https: = Erlaubt das Laden von allen Ressourcen aber nur über https
CSP Beispiel
Nun genug der Theorie, fangen wir einmal an, ein Szenario durchzuspielen. Du möchtest gerne auf deiner Webseite Twitter einbinden und dein ‘script-src’ besitzt den Wert ‘self’. Dadurch werden nur Inhalte von deiner Domain geladen. Inhalte wie JavaScript oder CSS Dateien müssen also von deiner Domain stammen.
Dadurch werden aber Dateien von Twitter nicht geladen. Um das zu ändern, klicke in deiner Inhaltsschutzrichtlinien-Verwaltung auf “Hinzufügen”.
Wähle script-src aus und füge als Wert ‘platform.twitter.com’ hinzu. Da Twitter mehrere Quellen verwendet, solltest du eine weitere Richtlinie hinzufügen. Also wieder “Hinzufügen” klicken, script-src auswählen und diesmal als Wert *.twimg.com eingeben.
Wenn du das ganze jetzt noch speicherst, werden ab jetzt Twitter-Inhalte erfolgreich geladen.
Durch CSP ist deine Seite nun ein Stückchen sicherer für dich und deine Besucher.
Wenn du mehr über CSP wissen möchtest, schreibe uns an.
In unserer Community haben wir immer ein offenes Ohr für dich.
Wir freuen uns auf dich.