Was macht es wirklich? Sie ermöglicht es Dritten, auf eine fehlerhafte Version Ihrer Website zu verlinken.
Es wird aktiv, wenn [einige Bedingungen erfüllt sind und] es eine Zeichenkette in der Abfrageübermittlung sieht, die auch wortwörtlich auf der Seite vorhanden ist und von der es glaubt, dass sie gefährlich sein könnte.
Sie geht davon aus, dass, wenn <script>something()</script> sowohl in der Abfragezeichenfolge als auch im Seitencode vorkommt, dann muss es daran liegen, dass Ihr serverseitiges Skript unsicher ist und die Zeichenfolge direkt als Markup ohne Escaping wieder ausgibt.
Abgesehen von der Tatsache, dass es sich um eine absolut gültige Abfrage handelt, die jemand zufällig eingegeben hat, ist es natürlich auch möglich, dass sie übereinstimmen, weil jemand die Seite angeschaut und absichtlich einen Teil davon kopiert hat. Zum Beispiel:
http://www.bing.com/search?q=%3Cscript+type%3D%22text%2Fjavascript%22%3E
Wenn Sie das im IE8 befolgen, habe ich Ihre Bing-Seite erfolgreich sabotiert, so dass sie Skriptfehler ausgibt und die Pop-out-Ergebnisse nicht funktionieren. Im Wesentlichen gibt es einem Angreifer, dessen Link verfolgt wird, die Lizenz, Teile der Seite, die ihm nicht gefallen, herauszusuchen und zu deaktivieren - und das könnte sogar andere sicherheitsrelevante Maßnahmen wie Framebuster-Skripte umfassen.
Was betrachtet der IE8 als "potenziell gefährlich"? Viel mehr und viel seltsamere Dinge als nur dieses Skript-Tag. z.B. . Darüber hinaus scheint er eine Reihe "gefährlicher" Vorlagen mit einem Textmustersystem (vermutlich Regex) abzugleichen, anstatt irgendeine Art von HTML-Parser zu verwenden, wie den, der schließlich die Seite selbst analysiert. Ja, wenn Sie IE8 verwenden, parst Ihr Browser HTML mit Regex.
XSS-Schutz' durch Betrachtung der Zeichenfolgen in der Abfrage ist völlig schwachsinnig . Sie kann nicht "repariert" werden; das Konzept selbst ist von Natur aus fehlerhaft. Abgesehen von dem Problem, dass es sich einmischt, wenn es nicht erwünscht ist, kann es Sie nur vor den einfachsten Angriffen schützen - und die Angreifer werden solche Blöcke sicher umgehen, wenn der IE8 weiter verbreitet ist. Wenn Sie vergessen haben, Ihre HTML-Ausgabe korrekt zu entschlüsseln, sind Sie immer noch angreifbar; alles, was Ihnen der XSS-"Schutz" zu bieten hat, ist ein falsches Gefühl von Sicherheit. Leider scheint Microsoft dieses falsche Gefühl der Sicherheit zu mögen; es gibt einen ähnlichen XSS-"Schutz" auch in ASP.NET, auf der Serverseite.
Wenn Sie also eine Ahnung von Webapp-Authoring haben und die Ausgabe in HTML wie ein guter Junge ordnungsgemäß escapen, ist es definitiv eine gute Idee, diesen unerwünschten, unpraktikablen und falschen Eingriff zu deaktivieren, indem Sie den Header ausgeben:
X-XSS-Protection: 0
in Ihren HTTP-Antworten. (Und mit ValidateRequest="false" in Ihren Seiten, wenn Sie ASP.NET verwenden).
Für alle anderen, die immer noch Strings in PHP aneinanderreihen, ohne darauf zu achten, richtig zu kodieren... nun, man kann es auch gleich anlassen. Erwarten Sie nicht, dass es Ihre Benutzer wirklich schützt, aber Ihre Website ist bereits kaputt, wen kümmert es also, wenn sie noch ein bisschen mehr kaputt geht, oder?
Um es in Aktion zu sehen, besuchen Sie eine AOL Food-Seite und klicken Sie auf das Symbol "Drucken" direkt über dem Artikel.
Ah ja, ich sehe, dass dies im IE8 nicht funktioniert. Es ist nicht sofort ersichtlich, wo der IE den Hack zum Inhalt gemacht hat, der die Ausführung gestoppt hat, obwohl... die einzige domänenübergreifende Anfrage, die ich sehen kann, die ein Kandidat für den XSS-Filter ist, ist diese an http://h30405.www3.hp.com/print/start :
POST /print/start HTTP/1.1
Host: h30405.www3.hp.com
Referer: http://recipe.aol.com/recipe/oatmeal-butter-cookies/142275?
csrfmiddlewaretoken=undefined&characterset=utf-8&location=http%253A%2F%2Frecipe.aol.com%2Frecipe%2Foatmeal-butter-cookies%2F142275&template=recipe&blocks=Dd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%28%2B.%2F%2C%28%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk%7Cpspm%3Db3%3Fd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%7D%2F%27%2B%2C.%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk...
dass blocks Der Parameter setzt sich seitenweise mit weiterem Kauderwelsch fort. Vermutlich gibt es etwas Dort spiegelt sich das (zufällig?) im zurückgegebenen HTML wider und löst eine der verkorksten Vorstellungen des IE8 aus, wie ein XSS-Exploit aussieht.
Um dieses Problem zu beheben, muss HP dafür sorgen, dass der Server unter h30405.www3.hp.com die X-XSS-Protection: 0 Kopfzeile.
