X-XSS-Protection

Nicht standardisiert: Diese Funktion ist nicht standardisiert und befindet sich nicht auf dem Weg zur Standardisierung. Verwenden Sie sie nicht auf Produktionsseiten, die dem Web ausgesetzt sind: Sie funktioniert nicht für alle Benutzer. Es kann auch große Inkompatibilitäten zwischen Implementierungen geben, und das Verhalten kann sich in Zukunft ändern.

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

Warnung: Obwohl diese Funktion Benutzer älterer Webbrowser, die noch keine Unterstützung für CSP haben, schützen kann, kann der XSS-Schutz in einigen Fällen XSS-Schwachstellen in ansonsten sicheren Websites erzeugen. Weitere Informationen finden Sie im Abschnitt unten.

Hinweis:

Das bedeutet, wenn Sie keine Unterstützung für veraltete Browser benötigen, wird empfohlen, Content-Security-Policy ohne zulässige unsafe-inline-Skripte zu verwenden.

Header-Typ Response Header
Verbotener Header-Name Nein

Syntax

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

Deaktiviert das XSS-Filtering.

1

Aktiviert das XSS-Filtering (in der Regel in Browsern standardmäßig). Wenn ein Cross-Site-Scripting-Angriff erkannt wird, wird der Browser die Seite bereinigen (die unsicheren Teile entfernen).

1; mode=block

Aktiviert das XSS-Filtering. 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 das XSS-Filtering. Wenn ein Cross-Site-Scripting-Angriff erkannt wird, bereinigt der Browser die Seite und meldet den Verstoß. Dies nutzt die Funktionalität der CSP report-uri-Direktive, um einen Bericht zu senden.

Schwachstellen verursacht durch XSS-Filtering

Betrachten Sie das folgende Beispiel von HTML-Code für eine Webseite:

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

Dieser Code ist völlig sicher, wenn der Browser kein XSS-Filtering durchführt. Führt er es jedoch aus und die Suchabfrage ist ?something=%3Cscript%3Evar%20productionMode%20%3D%20true%3B%3C%2Fscript%3E, könnte der Browser die Skripte auf der Seite ausführen und <script>var productionMode = true;</script> ignorieren (in der Annahme, der Server habe es in die Antwort eingefügt, weil es in der URI war), wodurch window.productionMode als undefined ausgewertet wird und unsicherer 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, sofern die Website in einem <iframe> eingebettet werden kann).

Beispiel

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

http
X-XSS-Protection: 1; mode=block

PHP

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

Apache (.htaccess)

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

Nginx

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

Spezifikationen

Nicht Teil von Spezifikationen oder Entwürfen.

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch