Der HTTP-X-XSS-Protection-Response-Header war ein Feature von Internet Explorer, Chrome und Safari, das das Laden von Seiten stoppte, wenn es reflektierte Cross-Site-Scripting (XSS) Angriffe erkannte.Diese Schutzmaßnahmen sind in modernen Browsern weitgehend unnötig, wenn Websites eine starkeContent-Security-Policy implementieren, die die Verwendung von Inline-JavaScript ('unsafe-inline') deaktiviert.

Es wird empfohlen,Content-Security-Policy anstelle der XSS-Filterung zu verwenden.

Syntax

X-XSS-Protection: 0X-XSS-Protection: 1X-XSS-Protection: 1; mode=blockX-XSS-Protection: 1; report=<reporting-uri>

Direktiven

0

Deaktiviert die XSS-Filterung.

1

Aktiviert die XSS-Filterung (normalerweise Standard in Browsern). Wenn ein Cross-Site-Scripting-Angriff erkannt wird, wird der Browser die Seite bereinigen (die unsicheren Teile entfernen).

1; mode=block

Aktiviert die XSS-Filterung. Anstatt die Seite zu bereinigen, wird der Browser das Rendern der Seite verhindern, wenn ein Angriff erkannt wird.

1; report=<reporting-URI> (nur Chromium)

Aktiviert die XSS-Filterung. Wenn ein Cross-Site-Scripting-Angriff erkannt wird, wird der Browser die Seite bereinigen und den Verstoß melden. Hierzu wird die Funktionalität der CSP-Direktivereport-uri verwendet, um einen Bericht zu senden.

Sicherheitsüberlegungen

Durch XSS-Filterung verursachte Schwachstellen

Betrachten Sie den folgenden Auszug von HTML-Code für eine Webseite:

<script>  var productionMode = true;</script><!-- [...] --><script>  if (!window.productionMode) {    // Some vulnerable debug code  }</script>

Dieser Code ist völlig sicher, wenn der Browser keine XSS-Filterung durchführt. Wenn er dies jedoch tut und die Suchanfrage?something=%3Cscript%3Evar%20productionMode%20%3D%20true%3B%3C%2Fscript%3E lautet, könnte der Browser die Skripte auf der Seite ausführen und<script>var productionMode = true;</script> ignorieren (da er denkt, der Server hätte es in die Antwort eingefügt, weil es in der URI war), was dazu führt, dasswindow.productionMode alsundefined ausgewertet wird und der unsichere Debug-Code ausgeführt wird.

Das Setzen desX-XSS-Protection-Headers auf entweder0 oder1; mode=block verhindert Schwachstellen wie die oben beschriebene. Ersteres würde den Browser alle Skripte ausführen lassen, während letzteres verhindern würde, dass die Seite überhaupt verarbeitet wird (obwohl dieser Ansatz anfällig fürSeitenkanalangriffe sein könnte, wenn die Website in einem<iframe> eingebettet werden kann).

Beispiel

Blockieren Sie das Laden von Seiten, wenn reflektierte XSS-Angriffe erkannt werden:

X-XSS-Protection: 1; mode=block

PHP

header("X-XSS-Protection: 1; mode=block");

Apache (.htaccess)

<IfModule mod_headers.c>  Header set X-XSS-Protection "1; mode=block"</IfModule>

Nginx

add_header "X-XSS-Protection" "1; mode=block";

Spezifikationen

Nicht Teil von Spezifikationen oder Entwürfen.

Browser-Kompatibilität

Siehe auch

• Content-Security-Policy
• Controlling the XSS Filter – Microsoft
• Understanding XSS Auditor – Virtue Security
• The misunderstood X-XSS-Protection – blog.innerht.ml