Warum CSP den Browser dazu veranlassen, verschiedene Vorgänge zu verhindern
Ein weit verbreiteter Abwehrmechanismus ist die Content Security Policy. Die Idee dahinter ist, dass der Webserver beim Ausliefern der eigentlichen Webseite noch zusätzliche Meta-Daten übermittelt, die den Browser dazu veranlassen - verschiedene Vorgänge zu verhindern & zu blocken.
Darunter zählen leider auch teilweise komplette Werbe & Marketing -Maßnahmen.
So ist es damit beispielsweise auch möglich- dass der Browser keine JavaScript-Dateien lädt und ausführt,
- dass komplette Webseiten leer bzw. weiß bleiben & kein Inhalt geladen wird,
- dass Seiten im Browser gar nicht erst aufgerufen & Verbindungen abgelehnt werden,
Beim Ausliefern des HTML-Dokuments bedarf es eines speziellen HTTP-Headers, der den Browser die Content Security Policy anwenden lässt. Dazu gibt es mehrere Möglichkeiten wie z.b. - <meta> Element im HTML-Code | serverseitige Scriptsprache | Konfiguration des Webservers
Wenn kein CSP-Header vom Server selbst versandt wird, kann man mit einem passenden <meta> Element nachhelfen. Sollte der Server irgendwann doch einen CSP-Header senden, hat dieser – wie in solchen Fällen üblich – für den Browser Vorrang, vor dem <meta> Element.
<!doctype html>
<head>
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<meta http-equiv="X-Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<meta http-equiv="X-WebKit-CSP" content="default-src 'self'; script-src 'self'">
<title>CSP nutzende Seite</title>
</head>
<body>
<h1>Sie sind sicher</h1>
<p>Dieses Dokument wurde mit einer sehr strikt eingestellten Content Security Policy ausgeliefert.</p>
</body>
</html>
Im Kopf des Dokuments ist ein <meta> Element notiert, welches den Browser erkennen lässt, dass er das Sicherheitskonzept anwenden soll. Die Anweisung default-src 'self' bedeutet, dass er prinzipiell nur zusätzliche Inhalte laden darf, wenn sie vom selben Server stammen. Die Anweisung script-src 'self' im content-Attribut erklärt dem Browser, dass er nur JavaScript-Dateien laden darf, die vom selben Server stammen wie dieses Dokument.
Diese Direktive hat eine zusätzliche Auswirkung: Der Browser darf keinen JavaScript-Code ausführen, der im HTML-Dokument selbst notiert ist.
Damit auch ältere Versionen des Browsers erreicht werden, benötigt es ein weiteres <meta> Element mit "X-Content-Security-Policy". Auch ältere Versionen von auf der Webkit-Engine basierenden Browsern (wie z. B. Chrome oder Safari) unterstützen vielleicht noch nicht standardmäßig die CSP und benötigen stattdessen "X-Webkit-CSP" als Header(-Ersatz).
Oft nutzen einige "WebHoster" div. CSP <meta> Elements, um Werbemaßnahmen & den damit verbundenen hohen Traffic zu unterbinden
<?php
header("Content-Security-Policy: default-src 'self'; script-src 'self'");
header("X-Content-Security-Policy: default-src 'self'; script-src 'self'");
header("X-WebKit-CSP: default-src 'self'; script-src 'self'");
Dieses Beispiel nutzt die PHP-interne Funktion header(), um einen HTTP-Header an den Browser zu senden.
Wie schon im HTML-Beispiel werden zusätzlich die angepassten Header "X-Content-Security-Policy" und "X-WebKit-CSP" mit ausgegeben.
Oft nutzen einige "WebHoster" Content Security Policy, um Werbemaßnahmen & den damit verbundenen hohen Traffic zu unterbinden
Wenn man seinen eigenen Webserver konfigurieren kann (was bei günstigen Hostingangeboten oder Wespace in aller Regel nicht der Fall ist) dann gibt es Einstellungsmöglichkeiten
Header set Content-Security-Policy "default-src 'self';"
server {
...
add_header Content-Security-Policy "default-src 'self';";
}
u.U. ist diese Einstellung nur dem "WebHoster" zugänglich. Falls im Kundenmenü nichts vorhanden ist, bitte beim zuständigen Support nachfragen.
Die Content-Security-Policy wird i.d.R. vom Webmaster (Webhoster) erstellt & auf jeder Unterseite der Website eingefügt, auf der der Mechanismus gelten soll.
Als Betreiber der Website haben Sie u.U. die Möglichkeit, unterschiedliche Mechanismen für jede einzelne Seite festzulegen. Unkompliziert realisieren Sie dies, indem Sie .htaccess-Dateien erstellen, und in den gleichen (oder hierarchisch höheren) Ordnern wie die entsprechenden Webseites abspeichern, oder indem Sie CSP direkt in die Server-Konfiguration verankern.
Die CSP funktioniert nach dem Prinzip einer Whitelist: Im Header werden die Quellen genannt, aus denen Skripte & Daten geladen werden dürfen.
Über die Content-Security-Policy können Webmaster viele weitere Einstellungen vornehmen, beispielweise durch diese Direktiven
- frame-ancestors
Legt fest, welche Domains erlaubt sind. - script-src
Bestimmt, welche Quellen für JavaScript erlaubt sind. - upgrade-insecure-requests
Stellt sicher, dass unsichere Seiten mit HTTP wie HTTPS-Seiten behandelt werden.
Unabhängig von der gesetzten CSP, wird u.a. auch zb. durch das Setzen von "x-frame-options:SAMEORIGIN" oder auch "x-frame-options:DENY" gleiches erziehlt. Hier sind entsprechende HTTP-Header X-Frame Optionen mit anzupassen.
einige Beispiele
X-Frame-Options: ALLOW-FROM https://example.com/
Content-Security-Policy: frame-ancestors 'self' https://example.com
X-Content-Type-Options: nosniff
Content-Security-Policy: frame-ancestors https://*.example.com https://*.example.de https://*.example.net www.beispielseite.de
Wenn Inhalte inkorrekt dargestellt oder geladen werden, zeigt beispielsweise der Mozilla-Firefox u.a. folgende Fehlermeldung
Firefox hat diese Webseite daran gehindert, auf diese Weise geladen zu werden, weil die Webseite eine Inhaltsicherheitsrichtlinie hat, die dies nicht erlaubt.
oder zb. bei Chrome folgende Fehlermeldung
www.beispielseite.de hat die Verbindung abgelehnt.
Einen ausführlichen Überblick zur CSP findet man u.a. beim Mozilla Developer Network
