X-XSS-Protection header
Deprecated
Avoid using this feature in new projects. This feature may be a candidate for removal from web standards or browsers.
Nicht standardisiert: Diese Funktion ist nicht standardisiert. Wir raten davon ab, nicht-standardisierte Funktionen auf produktiven Webseiten zu verwenden, da sie nur von bestimmten Browsern unterstützt werden und sich in Zukunft ändern oder entfernt werden können. Unter Umständen kann sie jedoch eine geeignete Option sein, wenn es keine standardisierte Alternative gibt.
Warnung:
Obwohl diese Funktion Nutzer älterer Webbrowser schützen kann, die CSP nicht unterstützen, kann X-XSS-Protection in einigen Fällen XSS-Schwachstellen in ansonsten sicheren Websites schaffen.
Siehe den Abschnitt Sicherheitsüberlegungen weiter unten für weitere Informationen.
Der HTTP X-XSS-Protection Antwortheader war eine Funktion von Internet Explorer, Chrome und Safari, die verhinderte, dass Seiten geladen werden, wenn sie reflektierte Cross-Site-Scripting (XSS)-Angriffe feststellten.
Diese Schutzmaßnahmen sind in modernen Browsern weitgehend überflüssig, wenn Websites eine starke Content-Security-Policy implementieren, die die Nutzung von Inline-JavaScript ('unsafe-inline') deaktiviert.
Es wird empfohlen, anstelle des XSS-Filters Content-Security-Policy zu verwenden.
| Header-Typ | Antwortheader |
|---|
Syntax
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
Direktiven
0-
Deaktiviert XSS-Filterung.
1-
Aktiviert XSS-Filterung (meistens 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 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 XSS-Filterung. Wenn ein Cross-Site-Scripting-Angriff erkannt wird, wird der Browser die Seite bereinigen und den Verstoß melden. Dies nutzt die Funktionalität der CSP
report-uri-Direktive, um einen Bericht zu senden.
Sicherheitsüberlegungen
Schwachstellen verursacht durch XSS-Filterung
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 jedoch die Suchanfrage ?something=%3Cscript%3Evar%20productionMode%20%3D%20true%3B%3C%2Fscript%3E ist, könnte der Browser die Skripte auf der Seite ausführen und <script>var productionMode = true;</script> ignorieren (in der Annahme, dass der Server es in die Antwort eingefügt hat, weil es im URI vorhanden war), was dazu führt, dass window.productionMode auf undefined ausgewertet wird und der unsichere Debug-Code ausgeführt wird.
Das Setzen des X-XSS-Protection-Headers auf entweder 0 oder 1; mode=block verhindert Schwachstellen wie die oben beschriebene. Ersteres würde den Browser alle Skripte ausführen lassen und letzteres würde verhindern, dass die Seite überhaupt verarbeitet wird (obwohl dieser Ansatz anfällig für Seitenkanalangriffe sein könnte, wenn die Webseite in einem <iframe> einbettbar ist).
Beispiel
Verhindern Sie, dass Seiten geladen werden, wenn sie reflektierte XSS-Angriffe feststellen:
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.