Aus gegebenen Anlass heute noch mal ein bisschen was zum Cross-Site-Scripting (siehe About Security #14/#15). Der Anlass: Anscheinend halten einige Entwickler Cross-Site-Scripting für harmlos. So z.B. der Entwickler des Content Management Systems QuickerSite, der eine gefundene Cross-Site-Scripting-Schwachstelle mit "[...] Injecting html, sql, javascript or anything in the search box above, will never compromise QuickerSite (although it is completely open source). Yes, it may have a funny effect in your browser (alone). [...]" kommentiert. Inzwischen wurde der Kommentar leider von der Seite entfernt und auch die angeblich nicht existierende Schwachstelle wurde anscheinend behoben. Eigentlich schade, ich hätte sonst an dieser Stelle gerne mal live demonstriert, was für einen 'funny effect' das im Browser haben kann. Und welcher Zusammenhang zwischen einem kompromittierten System und Open Source bestehen soll, weiß wohl auch nur der QuickerSite-Entwickler. Dass ein Hinweis auf die (vermutlich) behobene Schwachstelle fehlt, brauche ich wohl kaum noch zu erwähnen - das war ja zu erwarten: Wenn es keine Schwachstelle gibt, muss man ja auch deren Behebung nicht ankündigen.

Ein weiterer mit der Sicherheit etwas lässig umgehender Entwickler ist der des Support-Ticket-Sytems eTicket, der sich mit dem Beheben der gefundenen Schwachstellen allem Anschein nach nicht besonders viel Mühe gegeben und dann das Interesse daran verloren hat. Wenigstens scheinen letztendlich zumindest einige Schwachstellen behoben worden zu sein. Und dann sind da noch die Entwickler von ALEPH 500 und MetaLib, bei denen die gefundenen Schwachstellen ( in ALEPH, in MetaLib) kurzerhand wegdefiniert werden: "[...] The problem can only be replicated with IE, and FireFox is not officially supported for 3.13." Irgendwie verstehe ich das jetzt nicht: Die Schwachstelle tritt nur im IE auf, und Firefox wird nicht unterstützt - was hat das eine mit dem anderen zu tun? Schön, wenn sie im nicht-unterstützten Firefox nicht auftritt. Im (vermutlich doch wohl offiziell unterstütztem?) Internet Explorer, immerhin dem Windows-Standardbrowser, tritt sie auf. Reicht das nicht? Und was für Schlüsse soll man daraus ziehen? Wer deren Programme mit einem offizell unterstützten Browser benutzt, hat eben Pech gehabt? Gut zu wissen!

Da ich befürchte, dass es noch viele weitere Entwickler gibt, die Cross-Site-Scripting für einen ungefährlichen Angriff halten, der nur für Dumme-Jungen-Streiche genutzt wird, hier ein paar Beispiele für mögliche Folgen: Fangen wir mit den klassischen Cookie-"Diebstahl" an. Diebstahl ist dabei ziemlich unpassend, schließlich ist der Cookie ja noch da. Klingt harmlos? Ist es aber ganz und gar nicht. Vor allem nicht, wenn sich das angegriffene System für die Authentifikation ausschließlich auf den Cookie verlässt: Wer einen solchen Cookie kennt, kann dann alles tun, was auch der Benutzer tun kann. Wenn der dann zufällig Administrator-Rechte besitzt und/oder Dateien auf dem System anlegen kann, ist das System danach mit ziemlicher Sicherheit kompromittiert. Ein z.B. PHP-Skript mit einer Shell einzuschleusen ist dann keine Sache von Minuten, sondern Sekunden.

Aber auch wenn das System gar keine Cookies verwendet, kann Cross-Site-Scripting zum Ausspähen von Zugangsdaten verwendet werden. Für einen Phisher gibt es wohl nichts Verlockenderes als eine Cross-Site-Scripting-Schwachstelle auf einer Banken-Website. Da flugs eine eigene Anmelde-Seite eingefügt, und schon landen die Zugangsdaten auf seinem Server statt bei der Bank. Und was sich bei einer Bank lohnt, lohnt sich auch z.B. bei einem Webshop. Da wird dann eben nicht das Konto des Kunden geplündert, sondern auf dessen Kosten eingekauft.

Weiter geht's: Was ist mit z.B. Content-Management-Systemen, die aus dem Internet gar keine Änderungen zulassen? Die weder eine Cookie-basierte Authentifikation noch eine Login-Maske besitzen? Auch bei denen kann man mit Cross-Site-Scripting einiges Unheil anrichten. Über einige Möglichkeiten hatte ich ja im Standpunkt Sicherheit vom 4. September 2006 schon berichtet. Eigentlich hatte ich erwartet, die damals ausgenutzten Schwachstellen seien inzwischen behoben worden, zumal darüber damals auf mehreren Mailinglisten und Websites berichtet worden war. Zumindest bei der BBC scheint man davon nichts mitbekommen zu haben, die Lücke ist noch vorhanden und kann weiter ausgenutzt werden. Aber jetzt will ich das damals Geschriebene mal ein bisschen weiter ausmalen. Spam-Mails, mit denen Börsenkurse manipuliert werden sollen, hat in der letzten Zeit sicher jeder schon einmal bekommen. Dabei geht es immer darum, einen Kurs in die Höhe zu treiben, indem die Aktien als absoluter Geheimtipp angepriesen werden. Wäre so etwas nicht viel glaubwürdiger, wenn dabei ein Link auf eine Unternehmens- oder Nachrichtenwebsite mit passendem Inhalt mitgeliefert wurde? Ein Geheimtipp ist doch viel glaubwürdiger, wenn z.B. von der BBC darüber berichtet wird, oder? Oder wie wäre es mit einem vollkommen unbekannten Technologie-Unternehmen, das eine absolute Top-Neuheit herausbringen wird, die z.B. Apple im kommenden iPhone2 nutzen will? Passend dazu gibt es einen Link zur BBC, der das Ganze untermauert. Absolut glaubhaft, schließlich führt der Link zu einer vertrauenswürdigen Quelle! Da rotieren dann bestimmt bei einigen Leuten die €-Zeichen in den Augen und die Aktien werden geordert. Und irgend jemand macht aus seinen bisher nahezu wertlosen Aktien eine Goldgrube.

Und nun noch zwei abschließende Bemerkungen: Erstens: Wer meint, Cross-Site-Scripting sei nur ein Witz, sollte aufpassen, wer zuletzt lacht. Gut möglich, dass er selbst am Ende nichts zu lachen hat.

Und zweitens: Auch (bzw. in meinen Augen gerade) der Umgang mit gefundenen Schwachstellen sagt viel über die Tauglichkeit eines Programms für einen produktiven Einsatz aus! Wer schon eine so einfach durch simple Filterung der Eingaben zu schließende Schwachstelle nicht behebt - wie geht der dann mit wirklich kritischen Schwachstellen um? Möchte man so ein Programm wirklich einsetzen? Vor allem bei Webanwendungen, bei denen es für die meisten Zwecke mehr als genug Alternativen gibt? Eine Empfehlung ist das zumindest nicht, oder?

Carsten Eilers