Nachdem ich in den zwei vorhergehenden Artikeln über HSTS, X-XSS-Protection und die Content-Security-Policy geschrieben habe, folgen nun die letzten kleineren HTTP Security Header. Dazu zählen unter anderem X-Content-Type-Options, X-Frame-Options, Feature-Policy und Referrer-Policy. Auf der Webseite von OWASP, dem Open Web Application Security Project, findet ihr auch eine gute Übersicht aller Header, Einstellungsmöglichkeiten und Best Practices. Wie in den letzten Artikeln beschreibe ich die Umsetzung der Header mit Apache via .htaccess-Datei.

X-Content-Type-Options

Der Header ist recht simpel, denn er hat nur 1 mögliche Option: „nosniff“. Mit dieser Eigenschaft verhindert der Header, dass der Browser einen übermittelten Content-Type MIME type ändert. Stattdessen muss der MIME-Type in jedem Fall befolgt werden, was MIME sniffing Attacken (auch „content sniffing“ genannt) verhindern kann. Bei diesem Angriffsszenario werden Dateien mit einem falschen MIME-Type an den Browser geschickt, welcher diese dann anders als vorgesehen interpretiert:

Header always set X-Content-Type-Options "nosniff"

X-Frame-Options

Die Angabe eines X-Frame-Options Header gibt vor, ob andere Seiten deine Seite einbinden können – als frame, iframe oder object. Verhindert werden dadurch vor allem Clickjacking Attacken. Damit steht dies im Gegensatz zur CSP, welche die Einbindung anderer Seiten in deine Seite behandelt. Drei Optionen stehen zur Auswahl: DENY, SAMEORIGIN und ALLOW-FROM [Domain].
Für WordPress ist es empfehlenswert, die Option SAMEORIGIN zu wählen, da es sonst Problemen geben wird, beispielsweise beim Update von Plugins.

Header always set X-Frame-Options "SAMEORIGIN"

Feature-Policy

Die Feature-Policy ermöglicht die Kontrolle vieler Browser-APIs und somit die Einschränkung der Angriffsquellen bei vielen Funktionen. Für jede Direktive (= API) können folgende Optionen gesetzt werden: * (alle Quellen erlaubt), self, none, [Domains]. Die Funktionalität ist also der CSP sehr ähnlich, aber mit Fokus auf Features. Auch wenn die Browserunterstützung noch recht mau ist, empfehle ich die Nutzung: Beschränkt die einzelnen APIs so, wie sie in eurer Seite benötigt werden und schafft damit etwas mehr Sicherheit. Eine report-Direktive ist wohl schon in Arbeit, aber noch nicht implementiert, ich hoffe das kommt bald noch.

Mehr Informationen zu den Direktiven auf dieser Google-Seite, der Github Seite (manche davon ausführlicher erklärt) und aktiv gezeigt auf dieser Demo-Seite. Das reicht als Hilfe für das Setup.

Ich aktiviere bei mir die Features autoplay, fullscreen und picture-in-picture für ’self‘, allesamt für embedded Videos brauchbar, der rest wird mit ’none‘ deaktiviert:

Header always set Feature-Policy "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'self'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'self'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'self'; speaker 'none'; usb 'none'; vr 'none'"

Ihr findet diese und weitere Einstellungen auch in den Webseiten-Einstellungen, die für jede Webseite angepasst werden können. Eure lokalen Settings stehen dabei noch vor den von der Seite vorgegebenen Featureeinstellungen:

Referrer-Policy

Zuletzt noch die Referrer-Policy: Dieser Security Header steuert die Referrer-Information, die beim Aufruf eines Links auf eurer Seite mitgeschickt wird. Der Referrer ist dabei praktisch die Quelle der eingehenden Anfrage:

Grundsätzlich ist der Referrer eine nützliche Information, vor allem für Webseitenbetreiber und ihre Analysewerkzeuge wie Google Analytics. Sie erfahren, wie die Besucher auf die Webseite gekommen sind, von wo, eventuell mit welchen Suchbegriffen, und können ihre Seite mit diesen Informationen verbessern. Ich selber möchte hier also möglichst wenig restriktiv sein, aber dennoch die Sicherheit ein wenig erhöhen. Problematisch können Referrer-Informationen werden, wenn sie zu einer bösen oder unsicheren Seite weitergeleitet werden. Welche Möglichkeiten gibt es also?

Mögliche Optionen für die Referrer-Policy: no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url

Ich möchte jetzt hier nicht auf jeden Punkt eingehen, das wäre unnötig. Informiert euch gerne bei Mozilla (mitsamt Beispielen) oder in diesem Blog zu den Auswirkungen jeder Eigenschaft auf den Referrer.

Ich benutze aus oben genannten Gründen nur die Option ‚no-referrer-when-downgrade‚. Diese ist möglichst locker beim Aufruf beliebiger http://-Links und schickt den gesamten Referrer da mit. Ich habe in meinem Blog keine kritischen Informationen, die nicht weitergeschickt werden sollten. Allerdings wird die Weiterleitung meines Referrers auf unsichere http://-Seiten verhindert, das erhöht die Sicherheit ein wenig. Überdenkt eure Seite, eure Links und wie ihr mit dem Referrer selbst umgehen wollt.

Achtung WordPress-Nutzer: Ich glaube seit WordPress 4.7 werden target=“_blank“ Links automatisch mit der Eigenschaft rel=“noreferrer noopener“ erstellt. Das mag gute Hintergrundgedanken haben, wenngleich auch die Seite informiert, dass noopener den Angriff verhindert und noreferrer nur als compatibility backup benutzt wird.
Also unabhängig vom Referrer-Policy-Setting würden Links keinen Referrer mitsenden.
Es gibt mindestens 2 verschiedene Codes für die functions.php, mit der sich das deaktivieren lässt, beispielsweise siehe Link in diesem Absatz. Das Problem hierbei: Beide Codes funktionieren nicht mit dem neuen Gutenberg-Editor. Ich habe hier bisher keinen Weg gefunden, das automatische noreferrer zu entfernen und daher bleibt dieser Security Header bei mir mehr oder minder Placebo und für alle Fälle.

Fazit

Das waren nun also die wichtigsten sieben HTTP Security Header in drei Artikeln, das war doch eine ganze Menge neues Wissen. Ich hoffe, dass ihr etwas Hilfe finden und eure Webseitensicherheit ebenfalls verbessern konntet. Es gibt noch weitere Security Header, diese waren dann aber entweder kaum verbreitet, kaum unterstützt oder kritisch diskutiert und mir daher zu edge case für meine Artikel.

Im Großen und Ganzen bin ich zufrieden, auch wenn man sicher immer noch besser und sicherer sein kann, hier mein securityheaders.com Ergebnis:

Dieser Beitrag ist eine Fortsetzung der kleinen Artikelserie zur Optimierung der HTTP-Header für mehr Sicherheit auf der Webseite und für alle Webseitenbesucher. In Teil 1 ging es um die zwei noch recht einfachen Header HSTS und X-XSS-Protection. Teil 2 wird nun den recht komplexen aber mächtigen Header Content-Security-Policy behandeln.
Es benötigt vom Webmaster schon einiges an Vorbereitung und Testing, um mit diesem Header nicht auch Schaden anzurichten, aber der Zugewinn an Schutz gegenüber Angriffen oder Code Injection ist bemerkenswert.

CSP für umfangreiche Datenherkunftseinschränkung

Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. So können beispielsweise bestimmte Datentypen wie Skripte oder Stylesheets, die von einer anderen URL als der gerade zu ladenden Webseite angefragt werden, geblockt werden. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen, welche über zahlreiche Tricks versuchen, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.
Damit das jedoch so funktioniert, muss der Webmaster für alle oder einzelne Inhaltstypen die jeweiligen vertrauenswürdigen Quellen definieren. Hier wird es knifflig. Vergisst der Admin eine vertrauenswürdige Quelle, werden Inhalte von dort nicht mehr geladen und fehlen auf der Webseite. Das kann dazu führen, dass Schriftarten oder Bilder fehlen, Skripte und somit ganze Funktionen nicht mehr laufen und die Webseite sich in andere Seiten nicht mehr einbetten lässt. 
Die vertrauenswürdigen Ursprünge sind entweder bekannt oder müssen erarbeitet werden.

1. Informieren

Eine zu restriktiv gesetzte CSP kann die Webseite wie gesagt teilweise beschädigen. Ich empfehle daher die mehrstufige Vorgehensweise: Informieren, testen, optimieren und schlussendlich aktivieren.

Ein erster Blick lohnt beispielsweise bei MDN. Hier sehen wir, welche Direktiven und welche Werte möglich sind. Ich gehe später nochmal genauer auf die einzelnen Werte ein. Erst einmal solltet ihr euch einen groben Überblick holen. Nutzt für weitere Informationen neben diesem Artikel auch die Intros von html5rocks.com, SelfHTML, den Mehrstufen-Ansatz von dareboost.com und die dort verlinkten weiteren Artikel zu CSP-Basics und auch die vielen kleineren Webseiten und Blogger mit deren CSP-Empfehlungen.

2. Testen

Wir beginnen mit Tests, die keine Schäden anrichten können. Dazu nutzen wir das Report-Only Feature der CSP. Hierfür wird eine valide CSP über Content-Security-Policy-Report-Only gesetzt, angewendet aber nicht ausgeführt. Es werden Warnungen und Fehler ausgegeben, aber keine Anfragen tatsächlich blockiert. Gesetzt wird es wie gehabt in der .htaccess der Webseite:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self'; child-src 'self'; report-uri https://report-uri.de/report.php;"
</IfModule>

Der Inhalt dieser CSP ist erst einmal nur kopiert von kittpress.com und angepasst an das Report-Only Feature via .htaccess. Von hier arbeite ich mich dann weiter.

Die CSP wird nun theoretisch angewendet, aber nicht endgültig ausgeführt. Nun könnt ihr anhand der Browser-eigenen Dev-Tools und der Reports die Problemstellen identifizieren.
Wie ihr eine Report-Schnittstelle einrichtet, die beispielsweise Reports in eine Logdatei schreibt, habe ich im ersten Teil dieser Artikelserie erklärt. Ihr könnt auch genau dieselbe Reportschnittstelle hierfür nutzen, das funktioniert einwandfrei. Alternativ könnt ihr auch externe Report Services wie diesen als Ziel für eure Reports wählen.
Gegenüber euren Browsertools haben die Reports den Vorteil, dass jede CSP-Verletzung jedes Website-Besuchers an euch gemeldet wird – ohne, dass ihr dafür dann noch etwas tun müsst. Außerdem habt ihr alle Meldungen dann in einer großen und zentralen Server-Log (ggf. auch per Mail) und müsst nicht selbst rumsurfen und die Devtools abkopieren. Es geht ansonsten aber auch ohne report-uri.

3.1 Optimieren

Bei meinem ersten Test landeten weit über 100 Reports innerhalb von 1 Minute in der Report-Log – das reicht für eine erste Optimierung. Also habe ich die CSP erst einmal wieder deaktiviert/auskommentiert und die ersten Ausnahmen erstellt. Dazu habe ich mir jeden Report einzeln angesehen, wenn nötig eine Ausnahme erstellt, alle Logeinträge dieses spezifischen Problems entfernt, nächten Report angesehen. So lange, bis die Report-Log wieder leer war.
Anschließend die neue CSP wieder einkommentieren und wieder dreistellige Reports sammeln.
Diesmal dauert es länger und es kommen kleinere oder speziellere Probleme zum Vorschein: Von externen Seiten eingebundene Bilder oder Medien, alte http:// embeds von z.B. alten Google Maps Projekten, extern genutzte Services, Einbindungen von Inhalten noch über meine alte Domain hannes-schurig.de, externe Inhalte in Kommentaren usw.
Ich habe hier durchaus 2-3 Stunden verbracht, alte Blogartikel zu bearbeiten, Links zu korrigieren, meine alte Domain überall zu ersetzen, Kommentare zu korrigieren und mehr.
Nach 4-5 Iterationen über 3 Tage ist meine CSP nun ganz gut und die letzten 24 Stunden ergaben nur noch Reports, die geblockt werden können. Es verbleiben Logs von geblockten Domains wie countmake.cool, loadsource.org und eluxer.net – fragt mich nicht, was das ist. Manche Blocks kommen durch data, blob oder chrome-extension, ich denke das ist auch okay zu ignorieren.

Mit dieser Endfassung bin ich nun also ganz zufrieden und werde diese nun endgültig aktivieren:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; \
script-src 'self' 'unsafe-inline' 'unsafe-eval' www.google-analytics.com https://*.googleapis.com https://www.google.com https://www.gstatic.com https://*.vgwort.de https://*.it-stack.de; \
img-src 'self' https://*.gravatar.com https://*.w.org https://*.wordpress.org www.google-analytics.com https://*.vgwort.de https://www.gstatic.com https://*.it-stack.de data:; \
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://*.it-stack.de https:; \
font-src 'self' data: https:; object-src 'none'; \
child-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
frame-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
worker-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https; \
connect-src 'self' wss://it-stack.de www.google-analytics.com https://*.vgwort.de; \
report-uri https://report.tld/report.php"
</IfModule>

Die Backslashes am Ende der Zeilen ermöglichen Zeilenumbrüche in .htaccess Dateien zur besseren Lesbarkeit.

3.2 Verstehen

Ein paar kleinere Hinweise oder Ergänzungen dazu:

default-src ’self‘ wird angewendet, wenn eine andere Direktive, die für eine Anfrage gebraucht wird, gar nicht vergeben wurde. Ist eine Direktive gesetzt, wird default-src komplett überschrieben, dortige Werte werden nicht vererbt. Beispiel: img-src abc.com würde das ’self‘ von default-src nicht vererben, ’self‘ sollte daher fast immer mit angegeben sein.

Mir ist klar, dass unsafe-inline/-eval die größte Schwachstelle der CSP sind, allerdings auch das größte Problem bei WordPress Blogs mit etlichen Plugins, Google Analytics und mehr. Der Aufwand, diese zwei Attribute zu entfernen, kann sehr aufwändig und langwierig werden. Ich betrachte diese CSP jetzt vorerst als (wenn auch schon fortgeschrittenes) MVP – minimum viable product 😉

CSS-Stylesheets wirken eher harmlos, enthalten schließlich nur kosmetische Informationen, wieso einschränken? Es ist nicht zu unterschätzen, wieviel Spionage auch durch CSS-Angriffe wie z.B. „CSS Exfil“ möglich ist.

Ebenso Fonts, ist das nicht etwas too much? Nein, auch Fonts können zu Keyloggern umfunktioniert und müssen daher ebenso gut eingeschränkt werden.

child-src ist noch CSP Version 2 und wird angeblich (laut dieses Validators) in Version 3 durch frame-src und worker-src ersetzt. Ich habe also vorsichtshalber einfach mal alle drei Direktiven so gesetzt. Parallel am besten immer noch mit Google’s Validator testen.

4. Aktivieren

Nachdem die CSP nun definiert und einige Stunden ohne neue benötigte Regel im Testbetrieb lief, kann sie nun aktiviert werden. Dazu einfach nur Content-Security-Policy-Report-Only in Content-Security-Policy umschreiben und fertig. Beobachtet selber noch einmal die Webseite, auch das Admin Backend und wenn alles funktioniert, ist es geschafft!

Ich werde vorerst die Log noch im Blick behalten, bin aber erstmal froh, auch diesen Punkt soweit erledigt zu haben:

Zum Start dieser kleinen Serie, inspiriert durch einen Sicherheitsreport meines Blogs von enginsight.com (dazu mehr im November), erst einmal die Grundlagen der HTTP-Header:

Was sind HTTP-Header und wofür brauche ich sie?

HTTP-Header, oder in diesem Artikel vor allem die HTTP-Header-Respond-Felder, sind ein Teil der Antwort eines Webservers an den anfragenden Client (mehr dazu). Sie enthalten Anweisungen, Informationen und Einschränkungen der Verbindung zwischen Browser und Server, aufgebaut als eine Vielzahl an Schlüssel-Wert-Paaren.
Der Betreiber einer Webseite oder eines Webservers kann diese Antwortfelder teilweise konfigurieren und damit die Sicherheit der Webseite und des Verbindungsaufbaus erhöhen. Die Felder, die speziell für mehr Sicherheit entwickelt wurden, werden auch kurz HTTP-Security-Header genannt.

Die Anpassung der Header kann unterschiedlich erfolgen und ist vom Webserver oder der Webhosting Umgebung abhängig. Webserver bieten für HTTP gewöhnlich Konfigurationsdateien an, teilweise gibt es diesen Zugriff auch in root-Webhosting-Lösungen. Für „normales“ Webhosting geht das größtenteils auch über eine .htaccess in der obersten Ebene. Das könnte im Falle meines Webhosters All-Inklusive beispielsweise sein:
/www/htdocs/w00bxxxx/.htaccess

Mögliche Probleme mit .htaccess bei Shared Webhosting

Achtung: Eventuell werden Header Anpassungen von eurem Hoster geblockt/entfernt. Das liegt dann an der Art und Weise der Webserver-Konfiguration.
Sidestory: Bei meinem Hoster All-Inklusive, dessen Shared Hosting Server größtenteils PHP über FPM/FastCGI realisieren, ist das beispielsweise der Fall. Hier müssten die Einstellungen direkt im VHost gesetzt werden, das kann nur der Hoster selbst. Freundlicherweise hat mich All-Inkl nach einer Nachfrage auf eine moderne Serverfarm umgezogen, wo ich mittels .htaccess auch Header setzen kann.
Sollte das für euch nicht möglich sein, funktioniert für WordPress auch der Workaround über die functions.php, den ihr auf dieser Seite ganz unten im letzten Absatz findet. 
Teilweise kann es auch sein, dass die Einträge durch Einstellungen im Admin-Backend überschrieben werden. So kann es sein, dass HSTS, „Enforce SSL“ und ähnliche Domain-basierte Eigenschaften in der Domänenverwaltung angepasst werden und die .htaccess Angaben überschreiben.

Hier die Analyse meines Blogs von securityheaders.com vor der Optimierung der Security Header:

Kein sehr gutes Bild. Wird Zeit, daran zu arbeiten! Wir beginnen mit zwei recht unkomplizierten Security Feldern, HSTS und XSS-Protection. Sie bieten einen guten Einstieg in das Themengebiet und benötigen jeweils nur 1 Zeile in der .htaccess. Aber nun in die Details:

HTTP Strict Transport Security – SSL & HTTPS, bis dass der Tod uns scheidet

HSTS (HTTP Strict Transport Security) sollte ausschließlich aber unbedingt dann konfiguriert werden, wenn die Webseite SSL verschlüsselt (über https) erreichbar ist und nicht mehr über unverschlüsseltes HTTP erreichbar sein soll. HSTS gibt vor, dass und für welchen Zeitraum in der Zukunft alle Anfragen über SSL vom Client zum Server geschickt werden müssen.

<IfModule mod_headers.c>
  # Die einfache HSTS Variante, halbes Jahr Zeitfenster
  # Header always set Strict-Transport-Security "max-age=15778463"
  # oder noch sicherer mit Subdomains, preload und allen Subdomains
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Zwei Werte sind hier wichtig: max-age und der optionale Parameter includeSubDomains. max-age ist die Zeitangabe in Sekunden, wie lange der Zugriff in Zukunft für diesen gerade aufrufenden Client ausschließlich über SSL erfolgen muss. Der Wert 31536000 steht demnach für 1 Jahr. Ist die Webseite innerhalb dieser Zeit nicht über https erreichbar, weil beispielsweise das Zertifikat abgelaufen ist, kann sie nicht mehr geöffnet werden. Browser geben dann diese Art von Fehlermeldung und für den Nutzer ist hier Endstation. Das kann jetzt für den Nutzer doof sein, sorgt aber für ein hohes Sicherheitsminimum, das nicht unterschritten werden darf. Eigentlich ein Plus.

Ein Blick in die weiteren Eigenschaften von HSTS lohnt sich

Die zusätzliche Angabe includeSubDomains erweitert dieses Verfahren auf alle Subdomains, ein Wildcard-Zertifikat ist hier also von Nöten. 
Zu guter Letzt gibt es noch die preload-Eigenschaft, die noch nicht Teil des offiziellen Standards ist. Es ist die Crème de la Crème der HSTS-Absicherung und implementiert den HSTS-Schutz für eure Domain explizit und direkt in alle modernen Browser (akt: Chr, FF, Opr, Saf, IE11, Edg). Dafür muss die Seite jedoch HSTS ordentlich eingebunden haben und auf dieser Seite registriert werden. Dieser Artikel beschreibt sehr ausführlich und einfach dieses Attribut und all seine Details.
Prüft die HSTS-Eigenschaften eurer Seite beispielsweise hier. Mehr Informationen zu HSTS auch hier. Einen ausführlichen Check eurer SSL-Servereigenschaften könnt ihr hier initiieren – das dauert 2, 3 Minuten, ist aber sehr ausführlich und informativ.

X-XSS-Protection – steckt mehr drin als gedacht

Als nächste Eigenschaft schauen wir auf das Feld X-XSS-Protection. Dieses steuert Browser-Features, welche XSS-Attacken erkennen und verhindern. Diese Mechanismen sind normalerweise aktiviert, können aber von Servern oder vom Nutzer deaktiviert werden; X-XSS-Protection erzwingt die Nutzung dann entsprechend der Angabe. Oft lese ich, dass der Header nur von IE und Chrome, teilweise auch von Safari ausgewertet wird. Laut MDN wird der Header jedoch von allen Browsern bis auf Firefox unterstützt. Folgende Umsetzung via .htaccess:

<IfModule mod_headers.c> 
  # Schutz aktivieren und Rendern verhindern bei einem Angriff
  # Header always set X-XSS-Protection "1; mode=block" 
  # oder noch besser: Seite aufräumen, rendern und Angriff melden:
  Header always set X-XSS-Protection "1; report=http://reportingserver.com/reporting_URI.php
</IfModule>

Relativ einfach: Der erste Wert 1 erzwingt-aktiviert den Schutz, mode=block stoppt das Rendering der Seite und blockiert sie komplett. Ohne mode=block wird die Anfrage gereinigt und dann ausgeführt. Soweit so einfach.

XSS-Protection Reporting – Mitlesen der Angriffe

Nun kommt jedoch noch eine spannendere Anweisung, die leider auf kaum einer Infoseite beschrieben wird; vermutlich, weil es etwas mehr Text brauch. Denn die report-Anweisung ermöglicht die Angabe einer Reporting-URI, an die ein Bericht des Angriffs geschickt wird. Das dortige Skript kann nun beispielsweise loggen, benachrichtigen oder beliebig anders reagieren. Das finde ich besonders wert- und sinnvoll, daher hier noch der Aufbau:
Beginnen wir mit dem beispielhaften Aufbau eines XSS-Protection Report Requests, welcher mittels POST an die URI geschickt wird:

POST http://test.local/foo HTTP/1.1
Host: test.local
Connection: keep-alive
Content-Length: 116
Pragma: no-cache
Cache-Control: no-cache
Origin: http://test.local
X-FirePHP-Version: 0.0.6
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36
Content-Type: application/json
Accept: */*
DNT: 1
Referer: http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E
Accept-Encoding: gzip, deflate
Accept-Language: cs,en-US;q=0.8,en;q=0.6

{"xss-report":{"request-url":"http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E","request-body":""}}

Nun wird der Request gegen ein PHP-Skript geschickt und dort empfangen, in eine Datei geloggt und per Mail an den Admin geschickt. Dazu habe ich diesen MDN-Code etwas erweitert: Es gibt jetzt mehr Mailing-Optionen und die Möglichkeit, eine E-Mail bei jedem Angriff zu senden, statt nur beim ersten:

<?php
// Start configure
$log_file = dirname(__FILE__) . '/xss-report.log';
$log_file_size_limit = 10000000; // in bytes = 10MB - once exceeded no further entries are added
$email_every_attack = true;
$email_sender = 'phpmailer@mysite.de';
$email_recipient = 'admin@mysite.de';
$email_subject = 'XSS Violation';
$email_charset = 'utf-8';
// End configuration

$current_domain = preg_replace('/www\./i', '', $_SERVER['SERVER_NAME']);
$email_subject = $email_subject . ' on ' . $current_domain;
http_response_code(204); // HTTP 204 No Content
$json_data = file_get_contents('php://input');

// We pretty print the JSON before adding it to the log file
if ($json_data = json_decode($json_data)) {
  $json_data = json_encode($json_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
  if ($email_every_attack) {
    // Send an email
    $message = "XSS violation on " . $current_domain . ":\n\n" .
      $json_data . "\n\n" .
      "Logfile:" . $log_file;
    $headers =  "From: ".$email_sender."\r\n".
                "Content-Type: text/plain;charset=".$email_charset;
    mail($email_recipient, $email_subject, $message, $headers);
  } else if (filesize($log_file) > $log_file_size_limit) {
    exit(0);
  }
  file_put_contents($log_file, $json_data."\n", FILE_APPEND | LOCK_EX);
}
?>

Am besten testet ihr die Reporting-Funktion vorher, beispielsweise über einen online API-Tester. Baut euch einfach den Request zusammen und schickt ihn an eure Report-URI. Das funktioniert gut und dient mir nun als Informationsquelle, welche XSS-Angriffsversuche mit exakt welchen Anfragen gegen meine Seite gefahren werden. Hier nochmal das Setup visuell:

Es sei erwähnt, dass die X-XSS-Protection durch die neuere und komplexere Content Security Policy (CSP) ersetzt wird. Das schauen wir uns im nächsten Artikel genauer an. Solange dieses Feld aber noch nicht komplett von allen Browsern unterstützt wird, empfiehlt es sich weiterhin, XSS-Protection zu verbauen (zumal es so einfach ist).

Abschluss der ersten Optimierung

Die ersten zwei Security Header sind damit optimiert, ein erster Schritt: