Ich war gerade sehr überrascht, als ich im Zuge des Herumexperimentierens mit der Content Security Policy (kommt auch bald noch ein Artikel dazu – Update: Content Security Policy – Tutorial) folgendes Standard-Beispiel aufgebaut habe …
<input type="text" value="<?php echo $_GET['value']; ?>" />
… und dann das Standard-XSS-Pattern ?value=“><script>alert(1234)</script> übermittelt habe. Resultat im Chrome:
Bezieht sich übrigens nur auf die Injection von <script>-Tags, ein <b> – Tag geht also durch. Soweit ganz sinnvoll, kann mir jedenfalls keinen legitimen Fall vorstellen, wo ein script-Tag per URL-Parameter benötigt werden könnte. Im IE (ab Version 8) dasselbe Spiel:
Firefox ist das übrigens egal.
Wie ich nach etwas Recherche herausgefunden habe, nennt sich dieser Mechanismus XSS-Protection und ist in Webkit-basierenden Browsern bzw. eben dem IE standardmäßig aktiviert. Per Header lässt sich der Filter allerdings abschalten:
<?php header("X-XSS-Protection: 0"); ?>
So dann im Chrome:
Entsprechend im IE, ich spare mir und euch den Screenshot. Alternativ lässt sich das Verhalten noch konfigurieren:
header("X-XSS-Protection: 1; mode=block");
Dann wird die komplette Seite geblockt, sodass uns im IE folgendes erwartet:
Chrome zeigt einfach eine komplett leere Seite und gibt auch keinen Hinweis, etwa in Form einer Fehlermeldung. Prinzipiell eine sinnvolle Angelegenheit, das Verhalten vom IE gefällt mir hier sehr gut.
Nachfolgend ist eine offizielle Liste nützlicher HTTP Security Headers zu finden.
OWASP List of useful HTTP headers