Web-Sicherheit

September 16, 2011

Wie man den Cross-Site-Scripting-Filter von Googles Chrome umgeht

Filed under: Allgemein — sebastiankuebeck @ 15:53
Tags: , , , , , , ,

Googles aktueller Chrome Browser hat standardmäßig einen Filter gegen Cross-Site-Scripting-Angriffe eingebaut. Nick Nikiforakis zeigt auf seinem Blog, wie einfach man diese Schutzfunktion umgehen kann.

Damit man die geschilderte Angriffstechnik gleich ausprobieren kann, hat er folgendes PHP-Skripft veröffentlicht, dass die Parameter a und b in der URL entgegennimmt und ohne weitere Kodierung ausgibt:  http://securitee.org/files/chrome_xss.php.

Um zu testen, ob überhaupt eine Cross-Site-Scripting-Schwachstelle vorliegt, probieren wir erst einmal aus, ob der Überschrift-Tag in der folgenden Anfrage vom Browser ausgeführt wird (die meisten Filter reagieren lediglich auf Inhalte, die JavaScript enthalten oder nachladen. Begnügt man sich erst einmal mit einem harmlosen Tag, kann man einfach herausfinden, ob sich ein Angriff prinzipiell möglich ist):

http://securitee.org/files/chrome_xss.php?a=<h1>HTML_INJECTION<h1>&b=bar

Das funktioniert augenscheinlich ohne Probleme:

Der “naive” Versuch, einfach einen Script-Tag einzuschleusen, funktioniert hingegen nicht:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);</script>&b=bar

Chrome entfernt den Inhalt des Script-Tags bevor er die Seite anzeigt:

Als nächstes untersuchte Nick Nikiforakis was passiert, wenn man den Script-Tag nicht abschließt:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);&b=bar

Dabei zeigte sich, dass der Browser den Script-Tag nicht entfernte sondern automatisch schloss. Da allerdings alles, was nach dem Script-Tag kommt nun im JavaScript-Context ausgeführt wird, gibt der JavaScript-Interpreter auf und führt den Code nicht aus:

Was wir nun erreichen müssen ist, dass der Browser den HTML-Code zwischen den beiden Parametern ignoriert, die wir übergeben und das funktioniert, indem wir ihn in einen JavaScript-Kommentar einschließen:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);/*&b=*/</script>

Und das funkioniert auch, wovon man sich leicht überzeugen kann…

Nick hat das Problem dem Chrome-Team gemeldet, allerdings haben die Chrome-Entwickler noch keinen Weg gefunden, solche Angriffe zu verhindern. Dabei hat Nick nur an der Oberfläche gekratzt und bei weitem nicht alle bekannten Tricks, mit denen man solche Schwachstellen ausnutzen kann, ausprobiert (das “Standardwerk” zu diesem Thema ist übrigens das XSS Cheat Sheet auf ha.ckers.org).

Es zeigt sich also einmal mehr, dass man um das Absichern der Webanwendung selbst nicht herumkommt. Auch nicht mit noch so gut gemeinten Technologien auf Client- und Serverseite. Microsoft hat sich bei diesem Thema voriges Jahr auch die Finger verbrannt, denn eine Schwachstelle im Cross-Site-Scripting-Filter des Internet Explorer 9 führte dazu, dass Seiten, die bislang nicht verwundbar waren, durch den Filter plötzlich verwundbar wurden.

About these ads

Hinterlasse einen Kommentar »

Es gibt noch keine Kommentare.

RSS-Feed für Kommentare zu diesem Beitrag. TrackBack URI

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ photo

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

The Rubric Theme. Erstelle eine kostenlose Website oder einen kostenlosen Blog – auf WordPress.com!.

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

%d Bloggern gefällt das: