Content-Security-Policy ist ein HTTP-Security-Header, welcher das Ausnutzen von Cross-Site-Scripting (XSS) in Webseiten durch das Definieren von sicheren Javascript-Quellen unterbinden soll. Indem ein Webseitenbetreiber festlegt welche JS-Code-Segmente und Scripte ausgeführt werden dürfen, können Browser automatisch über XSS-Lücken eingeschleusten Code blocken.
In diesem Blogpost möchte ich jedoch nicht auf die Implementierung von CSP eingehen, sondern speziell die Report-Funktion ansprechen. Neben dem Blocken von nicht freigegebenen Ressourcen (JS, CSS, etc.) kann der Browser jegliche Verstöße gegen die definierten Richtlinien auch sofort an den Webseitenbetreiber berichten. Dafür muss in der CSP jedoch angegeben werden, wo diese Berichte hingehen sollen.
Die erste von zwei Möglichkeiten und aktuell noch die empfohlene Methode ist über die report-uri Option innerhalb der Richtlinie.
# Beispiel einer CSP mit Report-URI in Apache2
Header set "Content-Security-Policy default-src 'self'; style-src fonts.googleapis.com 'self'; report-uri /csp.php;"Diese Policy erlaubt sämtliche Datei-basierte Ressourcen vom eigenen Server (self), sowie Style-Ressourcen die von der Domäne fonts.googleapis.com geladen werden. Inline-Scripte (z.B. <script>code</script>), Inline-Styles (z.B. style="css-code") und Ressourcen von anderen Seiten werden geblockt. Wenn eine Anfrage oder eine Inline-Ressource geblockt wird, sendet der Browser einen Violation-Report (Bericht zum Verstoß gegen die Richtlinie) an die URL /csp.php, im Fall von LastBreach also https://www.lastbreach.de/csp.php.
Die zweite Methode verwendet die CSP-Option report-to, sowie den zusätzlichen Header Report-to und soll report-uri in Zukunft ersetzen. Der größte Vorteil von report-to ist das Bündeln von Berichten, sodass der Browser nicht jeden Verstoß einzeln übermitteln muss, aktuell wird sie jedoch noch von fast keinem Browser unterstützt.
Header set Report-To "{ 'group': 'lbcsp', 'max-age': 10886400, 'endpoints': [{ 'url': '/csp.php' }] }"
Header set "Content-Security-Policy default-src 'self'; style-src fonts.googleapis.com 'self'; report-to: lbcsp;"Die Übergangsphase ist aber dennoch unproblematisch, da Browser ohne Unterstützung für report-to diese Option vorerst einfach ignorieren. Somit kann eine kombinierte Lösung genutzt werden, bis report-uri komplett abgelöst wird.
Header set Report-To "{ 'group': 'lbcsp', 'max-age': 10886400, 'endpoints': [{ 'url': '/csp.php' }] }"
Header set "Content-Security-Policy default-src 'self'; style-src fonts.googleapis.com 'self'; report-uri /csp.php; report-to: lbcsp;"Das führt bei Firefox beispielsweise zu einer Warnung in der Browser-Konsole, dass report-to nicht unterstützt wird. Weiter passiert jedoch nichts. 
Der vom Browser gesendete Violation-Report sieht wie folgt aus und kann entweder direkt in eine Logdatei geschrieben oder an einen Log-Server weitergeleitet werden.
May 11 20:10:12 web01 cspreport: {
"csp-report":{
"blocked-uri":"self",
"document-uri":"https://www.lastbreach.de/services/penetrationtest-netzwerksicherheit-testen",
"original-policy":"default-src https://www.lastbreach.de; font-src https://fonts.gstatic.com https://www.lastbreach.com data:; report-uri https://www.lastbreach.com/csp.php",
"referrer":"https://www.google.com/",
"script-sample":"call to eval() or related function blocked by CSP",
"violated-directive":"script-src"
}
}Das oben verwendete PHP-Script ist äußerst einfach gehalten und leitet die Berichte an den lokalen Syslog-Dienst weiter, wo die Logdaten entsprechend verarbeitet werden können.
Alternativ können aber auch externe Dienste wie Report-URI verwendet werden, welche unter anderem auch eine grafische Aufbereitung der Daten bieten. Wer nicht bereits ein eigenes Programm zur Analyse von Logdaten betreibt, kann dies als Lösung in Erwägung ziehen.
Die Filterfunktionen in vielen grafischen Loganalyse-Tools erlauben das aussortieren von unwichtigen Informationen. Zusammen mit der grafische Auswertung der Daten kann die CSP-Report-Funktion bei der Implementierung und Optimierung der Policy helfen und später zum Erkennen von Angriffen und Schwachstellen dienen.
Unabhängig vom verwendeten Programm ist eine Analyse oder grafische Aufbereitung der Logdaten in jedem Fall zu empfehlen, da es nahezu unmöglich ist, eine sichere CSP-Richtlinie zu haben und selbst durch normale Besucher keine Verstöße in den Logs zu verzeichnen. Das liegt vor allem daran, dass viele Browser-Addons Javascript-Code in Webseiten einfügen, um funktionieren zu können. Da dieser Code jedoch von einer nicht freigegenen Quelle stammt und ein Webseitenbetreiber keine Ahnung hat, welche Addons die Besucher der Webseite einsetzen, werden diese eingefügten Code-Segmente vom Browser des Besuchers geblockt und berichtet.
# Beispiel einer CSP-Violation die durch das LastPass-Plugin in Firefox erzeugt wird (script-sample: ;undefined)
May 14 10:14:52 web01 cspreport: {
"csp-report":{
"blocked-uri":"self",
"document-uri":"https://www.lastbreach.de/",
"referrer":"",
"script-sample":";undefined",
"source-file":"https://www.lastbreach.de/",
"violated-directive":"script-src"
}
}Man kann daher nicht davon ausgehen, dass jeder Bericht im Log gleich einem Angriff entspricht. Dennoch bietet das Log bei ausreichender Analyse die Möglichkeit, Fehler in der Policy, aber auch XSS-Schwachstellen aufzudecken und diese entsprechend zu beheben.
