Was ist der http-Header "X-XSS-Schutz"?

Ich habe jetzt zum Spaß in Telnet mit HTTP herumgespielt (dh nur telnet google.com 80zufällige GETs und POSTs mit unterschiedlichen Headern und dergleichen eingegeben und eingegeben), aber ich bin auf etwas gestoßen, das google.com in seinen Headern überträgt, die ich habe Ich weiß es nicht.

Ich habe http://www.w3.org/Protocols/rfc2616/rfc2616.html durchgesehen und keine Definition für diesen bestimmten http-Header gefunden, den Google anscheinend herausspritzt:

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 01 Feb 2012 03:42:24 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6ddbc0a0342e7e63:FF=0:TM=1328067744:LM=1328067744:S=4d4farvCGl5Ww0C3; expires=Fri, 31-Jan-2014 03:42:24 GMT; path=/; domain=.google.com
Set-Cookie: NID=56=PgRwCKa8EltKnHS5clbFuhwyWsd3cPXiV1-iXzgyKsiy5RKXEKbg89gWWpjzYZjLPWTKrCWhOUhdInOlYU56LOb2W7XpC7uBnKAjMbxQSBw1UIprzw2BFK5dnaY7PRji; expires=Thu, 02-Aug-2012 03:42:24 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

1000

Weiß jemand was X-XSS-Protectionist?

X-XSS-Protection ist ein HTTP-Header, der von Internet Explorer 8 (und neueren Versionen) verstanden wird. Mit diesem Header können Domänen den "XSS-Filter" von IE8 ein- und ausschalten, wodurch einige Kategorien von XSS-Angriffen verhindert werden. In IE8 ist der Filter standardmäßig aktiviert, aber Server können ihn durch Einstellung ausschalten

   X-XSS-Protection: 0

Siehe auch http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header. aspx

• X-XSS-Protection: 1 : XSS-Schutz erzwingen (nützlich, wenn der Benutzer den XSS-Schutz deaktiviert hat)

• X-XSS-Protection: 0 : Deaktivieren Sie den XSS-Schutz

• Das Token mode=blockverhindert, dass Browser (IE8 + - und Webkit-Browser) Seiten rendern (anstatt zu bereinigen), wenn ein potenzieller XSS-Reflexionsangriff (= nicht persistent) erkannt wird.

/! \ Warnung, mode=blockerstellt eine Sicherheitsanfälligkeit in IE8 ( weitere Informationen ).

Weitere Informationen: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx und http://blog.veracode.com / 2014/03 / Richtlinien zum Einstellen von Sicherheitsheadern /

Dieser Antwortheader kann verwendet werden, um den integrierten reflektierenden XSS-Schutz eines Benutzeragenten zu konfigurieren. Derzeit unterstützen nur Microsoft Internet Explorer, Google Chrome und Safari (WebKit) diesen Header.

Internet Explorer 8 enthielt eine neue Funktion, mit der reflektierte Cross-Site-Scripting-Angriffe verhindert werden können, den so genannten XSS-Filter . Dieser Filter wird standardmäßig in den Sicherheitszonen Internet, Vertrauenswürdig und Eingeschränkt ausgeführt. Lokale Intranetzonenseiten können den Schutz mit demselben Header aktivieren.

Über den Header, den Sie in Ihrer Frage gepostet haben,

Der Header X-XSS-Protection: 1; mode=blockaktiviert den XSS-Filter. Anstatt die Seite zu bereinigen, verhindert der Browser das Rendern der Seite, wenn ein XSS-Angriff erkannt wird.

Im März 2010 haben wir die IE8-Unterstützung für ein neues Token im X-XSS-Protection-Header mode = block hinzugefügt.

X-XSS-Protection: 1; mode=block

Wenn dieses Token vorhanden ist und ein potenzieller XSS Reflection-Angriff erkannt wird, verhindert Internet Explorer das Rendern der Seite. Anstatt zu versuchen, die Seite zu bereinigen, um den XSS-Angriff chirurgisch zu entfernen, rendert der IE nur "#".

Internet Explorer erkennt einen möglichen Cross-Site-Scripting-Angriff. Es protokolliert das Ereignis und zeigt dem Benutzer eine entsprechende Nachricht an. Der MSDN-Artikel beschreibt, wie dieser Header funktioniert.

Wie dieser Filter im IE funktioniert ,

Weitere Informationen zu diesem Artikel finden Sie unter https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

Der XSS-Filter fungiert als IE8-Komponente mit Einblick in alle Anforderungen / Antworten, die durch den Browser fließen. Wenn der Filter wahrscheinlich XSS in einer standortübergreifenden Anforderung erkennt, identifiziert und neutralisiert er den Angriff, wenn er in der Antwort des Servers wiedergegeben wird. Benutzern werden keine Fragen gestellt, die sie nicht beantworten können. Der IE blockiert lediglich die Ausführung des schädlichen Skripts.

Mit dem neuen XSS-Filter erhalten IE8 Beta 2-Benutzer, die einem XSS-Angriff vom Typ 1 ausgesetzt sind, eine Benachrichtigung wie die folgende:

IE8 XSS-Angriffsbenachrichtigung

Die Seite wurde geändert und der XSS-Angriff wird blockiert.

In diesem Fall hat der XSS-Filter einen Cross-Site-Scripting-Angriff in der URL identifiziert. Dieser Angriff wurde kastriert, da das identifizierte Skript wieder auf der Antwortseite wiedergegeben wurde. Auf diese Weise ist der Filter wirksam, ohne eine erste Anforderung an den Server zu ändern oder eine gesamte Antwort zu blockieren.

Das Ereignis Cross-Site Scripting Filter wird protokolliert, wenn Windows Internet Explorer 8 einen Cross-Site Scripting-Angriff (XSS) erkennt und abschwächt. Cross-Site-Scripting-Angriffe treten auf, wenn eine im Allgemeinen böswillige Website JavaScript-Code in ansonsten legitime Anforderungen an eine andere Website einfügt (hinzufügt). Die ursprüngliche Anforderung ist im Allgemeinen unschuldig, z. B. ein Link zu einer anderen Seite oder ein CGI-Skript (Common Gateway Interface), das einen gemeinsamen Dienst bereitstellt (z. B. ein Gästebuch). Das injizierte Skript versucht im Allgemeinen, auf privilegierte Informationen oder Dienste zuzugreifen, die die zweite Website nicht zulassen möchte. Die Antwort oder die Anfrage spiegelt im Allgemeinen die Ergebnisse auf der schädlichen Website wider. Der XSS-Filter, eine neue Funktion in Internet Explorer 8, erkennt JavaScript in URL- und HTTP-POST-Anforderungen. Wenn JavaScript erkannt wird, Der XSS-Filter sucht nach Reflexionsnachweisen, Informationen, die an die angreifende Website zurückgegeben würden, wenn die angreifende Anfrage unverändert übermittelt würde. Wenn eine Reflexion erkannt wird, bereinigt der XSS-Filter die ursprüngliche Anforderung, sodass das zusätzliche JavaScript nicht ausgeführt werden kann. Der XSS-Filter protokolliert diese Aktion dann als Cross-Site Script Filter-Ereignis. Das folgende Bild zeigt ein Beispiel für eine Site, die geändert wurde, um einen Cross-Site-Scripting-Angriff zu verhindern.

Quelle: https://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx

Webentwickler möchten möglicherweise den Filter für ihren Inhalt deaktivieren. Sie können dies tun, indem Sie einen HTTP-Header festlegen:

X-XSS-Protection: 0

Mehr zu Sicherheitsköpfen in,

• Richtlinien zum Festlegen von Sicherheitskopfzeilen

• Sicherheits-HTTP-Header - X-XSS-PROTECTION

• MDN Docs X-XSS-Schutz

Sie können in dieser Liste nützliche HTTP-Header sehen .

X-XSS-Schutz: Dieser Header aktiviert den XSS-Filter (Cross-Site Scripting), der in den neuesten Webbrowsern integriert ist. Es ist normalerweise sowieso standardmäßig aktiviert, daher besteht die Rolle dieses Headers darin, den Filter für diese bestimmte Website wieder zu aktivieren, wenn er vom Benutzer deaktiviert wurde. Dieser Header wird in IE 8+ und in Chrome unterstützt (nicht sicher, welche Versionen). Der Anti-XSS-Filter wurde in Chrome 4 hinzugefügt. Es ist nicht bekannt, ob diese Version diesen Header berücksichtigt.

TL; DR: Alle gut geschriebenen Websites (/ Apps) müssen Header ausgeben X-XSS-Protection: 0und diese Funktion einfach vergessen. Wenn Sie zusätzliche Sicherheit wünschen, die bessere Benutzeragenten bieten können, verwenden Sie einen strengen Content-Security-PolicyHeader.

Lange Antwort:

Der HTTP-Header X-XSS-Protectionist eines der Dinge, die Microsoft in Internet Explorer 8.0 (MSIE 8) eingeführt hat, um die Sicherheit falsch geschriebener Websites zu verbessern.

Die Idee ist, eine Art Heuristik anzuwenden, um zu versuchen, einen Reflexions-XSS-Angriff zu erkennen und den Angriff automatisch zu neutralisieren.

Der problematische Teil davon ist "Heuristik" und "Kastration". Die Heuristik führt zu Fehlalarmen und die Kastration kann nicht sicher durchgeführt werden, da sie Nebenwirkungen verursacht, mit denen XSS-Angriffe und DoS-Angriffe auf absolut sichere Websites implementiert werden können.

Der schlechte Teil ist, dass sich X-XSS-Protectionder Browser so verhält, als ob der Header ausgegeben X-XSS-Protection: 1worden wäre , wenn eine Website den Header nicht ausgibt. Das Schlimmste ist, dass dieser Wert der am wenigsten sichere Wert aller möglichen Werte für diesen Header ist!

Für eine gegebene sichere Website dieses „XSS - Schutz“ -Funktion (das heißt, funktioniert die Seite nicht Reflexion XSS - Schwachstellen hat) ermöglicht folgende Angriffe:

X-XSS-Protection: 1Ermöglicht dem Angreifer, Teile von JavaScript selektiv zu blockieren und den Rest der Skripte am Laufen zu halten. Dies ist möglich, weil die Heuristiken dieser Funktion einfach lauten: "Wenn der Wert eines GET-Parameters im Skriptteil der Seitenquelle gefunden wird, wird das Skript automatisch in Abhängigkeit vom Benutzeragenten geändert." In der Praxis kann der Angreifer z. B. Parameter hinzufügen, disablexss=<script src="framebuster.js"und der Browser entfernt die Zeichenfolge automatisch <script src="framebuster.js"aus der eigentlichen Seitenquelle. Beachten Sie, dass der Rest der Seite weiterhin ausgeführt wird und der Angreifer diesen Teil der Seitensicherheit entfernt hat. In der Praxis kann jedes JS in der Seitenquelle geändert werden. In einigen Fällen kann eine Seite ohne XSS-Sicherheitsanfälligkeit mit reflektiertem Inhalt verwendet werden, um aufgrund der Kastration ausgewähltes JavaScript auf einer Seite auszuführen indem er Klartextdaten fälschlicherweise in ausführbaren JavaScript-Code umwandelt .

X-XSS-Protection: 1; mode=blockErmöglicht es dem Angreifer, Daten aus der Seitenquelle zu verlieren, indem das Verhalten der Seite als Seitenkanal verwendet wird. Wenn die Seite beispielsweise JavaScript-Code in var csrf_secret="521231347843"Anlehnung an enthält , fügt der Angreifer einfach einen zusätzlichen Parameter hinzu, z. B. leak=var%20csrf_secret="3und wenn die Seite NICHT blockiert ist, wird der3 war die erste Ziffer falsch. Der Angreifer versucht es erneut, diesmal wird leak=var%20csrf_secret="5das Laden der Seite abgebrochen. Dadurch kann der Angreifer erkennen, dass die erste Ziffer des Geheimnisses ist 5. Der Angreifer errät dann weiterhin die nächste Ziffer.

Wenn Ihre Site voll von XSS-Reflexionsangriffen ist, 1wird die Angriffsfläche durch Verwendung des Standardwerts von ein wenig reduziert. Wenn Ihre Site jedoch sicher ist und Sie nicht emittierenX-XSS-Protection: 0 , ist Ihre Site für jeden Browser anfällig, der diese Funktion unterstützt. Wenn Sie eine umfassende Unterstützung von Browsern gegen noch unbekannte XSS-Schwachstellen auf Ihrer Website wünschen, verwenden Sie einen strengen Content-Security-PolicyHeader. Dadurch wird Ihre Website nicht für bekannte Sicherheitslücken geöffnet.

Derzeit ist diese Funktion in MSIE, Safari und Google Chrome standardmäßig aktiviert. Dies war früher in Edge aber aktiviert Microsoft hat diese Fehlfunktion bereits aus Edge entfernt . Mozilla Firefox hat dies nie implementiert.

Siehe auch:

https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html https://blog.innerht.ml/the-misunderstood-x-xss-protection/ http: / /p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf https://www.slideshare.net/masatokinugawa/xxn-de https://bugs.chromium.org/p/chromium/issues/detail?id=396544 https: // bugs.chromium.org/p/chromium/issues/detail?id=498982