Cross Site Scripting? Nein Danke! Marc Ruef | 04.09.2006 Web-Dienste stellen mittlerweile das Rückgrat, oder wenigstens eines davon, der modernen Informationsverbreitung dar. Kaum ein Unternehmen bietet nicht im World Wide Web eine Vorstellung von sich selbst, erweiterte Interaktion mit potentiellen oder existenten Kunden an. So manche Firma hat gar das Web als Plattform für das Umsetzen von Geschäften und damit E-Commerce für sich entdeckt. Aus diesem Grund ist es nicht selten gegeben, dass bei einer Sicherheitsüberprüfung Webserver und Webapplikationen eine zentrale Rolle spielen. Fehlende oder fehlerhafte Eingabeüberprüfungen sind nach wie vor die Grundlage für eine Vielzahl an Angriffsformen. Da die meisten Programmier-Einsteiger ob der Einfachheit von Technologien wie HTML und PHP ihre ersten Gehversuche mit Webanwendungen machen, ist es entsprechend eher gegeben, dass genau in diesen Bereichen auf technische Schutzmechanismen verzichtet wird. Unerfahrenheit, Unwissen und Unachtsamkeit spielen dabei die Hauptrollen. Die Folge davon ist, dass die meisten Webanwendungen, wenn sie denn erst frisch auf den Markt gekommen sind oder noch nie einem umfassenden Penetration Test unterzogen wurden, einige unschöne Schwachstellen aufweisen. Dabei spielen im Webbereich gerade Cross Site Scripting und SQL Injection eine wichtige Rolle. Pufferüberlauf- und Format String-Attacken können zwar auch gegeben sein, sind statistisch in den Applikationen selbst eher weniger anzutreffen (Eher im Webserver oder dem Interpreter der Web-Sprache). Es gibt selten Web Application Penetration Test Projekte, bei denen ich nicht früher oder später wenigstens eine, manchmal doch eher esoterische, Cross Site Scripting-Schwachstelle identifizieren kann. Spätestens wenn es um die Interpretation von Cookie-Informationen geht, versagen die meisten Anwendungen. Die Entwickler dieser rechnen halt einfach nicht damit, dass eine solch vermeintlich statische Information manipulativ eingesetzt und damit erweiterte Rechte angestrebt werden kann. Gerade weil das Finden derartiger Sicherheitslücken sehr einfach ausfällt, ist es umso eher unverständlich, dass es gerade diese Angriffsform ist, die bei der Besprechung des Audit Reports die meisten Diskussionen verursacht. Viele Kunden, Berater und Entwickler verstehen einfach nicht, wie Cross Site Scripting funktioniert. Dabei werden die Risiken gerne missverstanden und dann heruntergespielt. Die Erklärung der Funktionsweise einer klassischen Cross Site Scripting-Attacke der Form des Cookie-Stealings ist aber auch schwer zusammenzufassen: "Ein Angreifer bereitet einen Webserver vor, auf dem er Anforderungen des zukünftigen Opfers entgegennehmen kann. Nun schickt er dem Opfer einen präparierten Link einer legitimen Seite. Durch den Aufruf dieser URL wird nun der Script-Code in die Zielanwendung injiziert, von ihr zurückgegeben und vom Webbrowser des Benutzers ausgeführt. Letzterer liest nun automatisch die sensitiven Cookie-Informationen aus und ruft mit ihnen als Parameter den vorbereiteten Webserver auf. Unter anderem kann nun in den Log-Dateien des Webservers die entsprechende Cookie-Information eingesehen werden. Diese Daten lassen sich nun missbrauchen." Eine beliebte Position innerhalb des Streitgesprächs ist es sodann, dass sich durch Cross Site Scripting keine direkten Informationen aus der Zielanwendung extrahieren lässt. Dazu sei noch immer die Interaktion mit dem Benutzer erforderlich und deshalb nur eine Second Order Attacke gegeben. Und dabei ist ja auch höchstens nur Script-Code im Webbrowser dessen ausführbar. Damit liesse sich ja keine effektiven Angriffe umsetzen. Das Finden und konstruktive Ausnutzen von Pufferüberlauf-Schwachstellen gilt seit jeher als Königsdisziplin. Der Angreifer muss eine Vielzahl an komplexen Technologien verstehen. Der Umgang mit Disassembler und Debugger sowie das Wissen um Programmiersprachen, Assembler und Speicherregister macht derartige Attacken zu einem schwierigen Verfahren. Dennoch können Pufferüberlauf-Schwachstellen im Gegensatz zu Cross Site Scripting-Zugriffen viel einfacher zusammengefasst werden, da es sich um First Oder Angriffe handelt: "Durch die fehlerhafte Behandlung von Eingaben ist es einem Angreifer möglich, den Speicher des Systems zu überschreiben und damit den Programmfluss zu ändern, um zum Beispiel beliebigen Programmcode auszuführen." Cross Site Scripting setzt auf einfachere Technologien, ist aber ebenso von einer Vielzahl an Methoden abhängig. Da das Verständnis dieser jedoch zwingend erforderlich ist, um die mehrstufigen Attacken als Möglichkeit zu verstehen, ist das Erarbeiten des grundlegenden Verständnisses für diese Angriffsform für den Laien schwieriger. Das vielschichtige Risiko von Script-Injection darf jedoch nicht unterschätzt werden: 1. Zum einen lassen sich damit direkte Angriffe auf den Webbrowser eines Benutzers umsetzen. Weist die gegebene Software Fehler beim Rendering von Seitenanweisungen (HTML/XHTML) und der Interpretation von mobilem Programmcode (Javascript, Java, Flash, ...) auf, kann eine direkte Kompromittierung des Systems des Besuchers erfolgen. Die Angriffsfläche von Webbrowsern (egal ob Microsoft Internet Explorer oder Mozilla Firefox) ist enorm und die Chancen gross, dass sich ein solcher Zugriff dank Cross Site Scripting initiieren lässt. 2. Desweiteren ist es denkbar, dass durch das Einschleusen von eigenem HTML-Code oder des Ändern des Verhaltens der Applikation, eine technisch gestützte Phishing-Attacke realisierbar wird. Können Downloads von vermeintlich wichtigen Applikationen erzwungen werden (z.B. Update der Banking-Anwendung), lassen sich sehr einfach korrupter Programmcode (Hintertüren) einschleusen. Die Infektion findet dabei manuell durch den leichtgläubigen Benutzer statt. Oder innerhalb eines eingebetteten Frames wird eine alternative Authentisierung auf einem anderen Server vorgegaukelt und die Eingaben dieser Abgefangen. Da er sich in einem legitimen Kontext der gewollt aufgesuchten Webseite befindet, die er als vertrauenswürdig einstuft, ist er der Manipulation schlichtweg ausgeliefert. 3. Und dann bleiben halt noch immer die Angriffe auf Cookies. Durch das automatische Auslesen dieser wird es unter Umständen möglich, sich eine legitme Benutzer-Sitzung zu erschleichen. Gerade wenn Authentisierungs-Informationen (Benutzername/Passwort) oder Sitzungs-Daten (Session-ID der authentisierten Sitzung) in Cookies gespeichert werden, können diese Informationen genutzt werden, um die Authentisierung zu umgehen. Ein Posting, das zwar nicht wirklich eine akademische Neuerung in Bezug auf Cross Site Scripting postuliert, wurde auf Bugtraq und Full-Disclosure publiziert (Attacking the local LAN via XSS (http://www.securityfocus.com/archive/1/442483/30/360/threaded), pdp, 04. August 2006). In diesem ist die Rede davon, wie durch Cross Site Scripting-Attacken ganze LANs unter Kontrolle gebracht werden können. Es bestehen gar schon Ideen, diese Technologien für das Umsetzen von Remote-Control-Backdoors im Sinne von BackOrifice und NetBus zu nutzen. Und dies alles mit den vermeintlich uninteressanten Technologien HTML, Javascript und SOAP/WSDL. Es gibt viele alteingesessene Hacker, die sich darüber beklagen, wie sehr doch die Szene am verkommen ist. Dabei wird gerne darüber geschimpft, dass es keine interessanten Exploiting-Techniken mehr gibt und ja sowieso nur noch uninteressante Cross Site Scripting-Schwachstellen publiziert werden. Obschon es wirklich gegeben scheint, dass die "goldenen Jahre der Computersicherheit" vorüber sind, sollten die Risiken von Script-Injection nicht unterschätzt oder heruntergespielt werden. Auch wenn eine Angriffstechnik banal und uninteressant erscheint, muss sie nicht zwingend ungefährlich sein. Es bleibt also richtig und wichtig auch weiterhin Angriffsvektoren dieser Art zu finden, analysieren und diskutieren.