Eine öffentliche Webseite birgt oft viele Angriffsflächen:
und viele andere.
XSS-Angriffe nutzen das Vertrauen des Browsers in die vom Server empfangenen Inhalte aus. Da der Browser der Quelle des Inhalts vertraut, werden auch bösartige Skripte vom Browser des Benutzers standardmäßig ausgeführt. Selbst wenn diese Skripte nicht von dort kommen, wo sie zu herzukommen scheinen.
Das Ziel der CSP ist es, unter anderem solche XSS-Angriffe zu erkennen und zu verhindern. Das geschieht, in dem der Webserver einen Header schickt mit Informationen, für welche Dateien und Daten welche Quellen sicher sind. Ein Header ist der Teil einer Anfrage und Antwort, der immer als erstes mitgesendet wird. Zum Beispiel schickt der Browser im Header meistens auch die akzeptierten Sprachen, der die Benutzerin versteht.
Es gibt dafür eine Zwischenlösung. Statt also gleich den Header zu setzen wird ein Report-Only-Header gesetzt. Nun kann in der Browser-Konsole oder mit einem Skript auf dem Server nachgelesen werden, wo es hakt. Dazu muss die gesamte Website durchkämmt werden. Das kann mit automatisierten Tools geschehen oder manuell, wenn es nur wenige zu testenden Seiten sind. Alternativ oder zusätzlich kann, wenn das der Hauptfokus ist wie hier im Beispiel, auch nach verräterischen Inline-Skripten geschaut werden. Wenn Sie die Webseite als Container betreiben oder diese auch sonst (z. B. bei einer vornehmlich statischen Seite) offline oder auf einem Testsystem testen können, wäre das Testen dort vorzuziehen.
Es sei denn, Sie und die Webseiteinhaberin haben viel Humor.
Aufspüren von Inline-Skripts in einem Hugo-Template:
find themes -name "*.html" -print0 | xargs -0 grep "<script>"
Eine Verletzung der CSP kann in der Browserkonsole zum Beispiel so aussehen:
Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf inline blockiert ("script-src"). www.example.de
Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf inline blockiert ("script-src"). www.example.de:9:1
Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf data:image/svg+xml,%3Csvg xmlns=%22http:… blockiert ("img-src").
Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf data:image/svg+xml,%3csvg xmlns='http://… blockiert ("img-src").
Eine Ausgabe auf dem Server (naja, allerdings durch den Browser der Nutzerin) kann zum Beispiel so aussehen:
{
"csp-report":{
"blocked-uri":"inline",
"column-number":1,
"document-uri":"https://www.example.com/",
"line-number":9,
"original-policy":"default-src 'self' https://*.example.com https://*.example.de; img-src *; media-src *; script-src https://*.example.com https://*.example.de; report-uri https://www.example.com/csp-report.php",
"referrer":"",
"source-file":"https://www.example.com/",
"violated-directive":"script-src"
}
}
Content-Security-Policy "default-src 'self' *.example.com *.example.de; img-src *; media-src *; script-src *.example.com *.example.de"
Content-Security-Policy-Report-Only "default-src 'self' *.example.com *.example.de; img-src *; media-src *; script-src *.example.com *.example.de; report-uri /csp-reporter.php"