Die wichtigste Frage zum Thema Webwürmer lautet schlicht und einfach: Wie man man sie verhindern? Oder genauer: Wie verhindert man, dass Webwürmer eine Webanwendung angreifen können, und wie verhindert man ihre Ausbreitung, sollte es doch einmal zu einem Angriff kommen?

Etwas Theorie

Am 4. Januar 2008 wurde von RSnake der 'Diminutive XSS Worm Replication Contest' ausgerufen. Das Ziel: Den kürzest möglichen, sich selbst verbreitenden XSS-Wurm zu finden. Die Ergebnisse wurde in diesem Forum-Thread auf sla.ckers.org gesammelt. Einen Zwischenbericht gibt es hier und das Ergebnis hier. Der kürzeste (für den Wettbewerb eingereichte) Wurm ist nur 161 Byte lang.

Während der Wettbewerb lief, gab es einige Diskussionen darüber, ob damit nicht den Angreifern in die Hände gespielt wird, siehe z.B hier und hier. Würde man dieser Argumentation folgen, dürfte man gar nichts mehr über Schwachstellen und mögliche Angriffe schreiben, schließlich könnten auch diese Informationen von Angreifern ausgenutzt werden. Und das ist eindeutig Unsinn. Ganz im Gegenteil: Natürlich müssen mögliche Angriffe diskutiert werden, wie sollte man sich sonst dagegen schützen? Um einen Angriff abzuwehren, muss man ihn erst einmal erkennen. Die im Rahmen des Wettbewerbs gesammelten Wurmbeispiele können natürlich mit einer schädlichen Payload versehen werden. Aber da diese Muster jetzt bekannt sind, kann man entsprechende Gegenmaßnahmen ergreifen. Das ist genau wie beim XSS-Cheatset: Gegen die darin gesammelten Möglichkeiten, XSS-Code zu tarnen und damit Filter zu unterlaufen, kann man sich schützen.

RSnake hat die Schlussfolgerungen aus den Ergebnissen des Wettbewerbs in einem sehr interessanten Artikel zusammengefasst: 'XSS Worm Analysis And Defense'.

Gegenmaßnahmen

Die Benutzer können wenig tun. Die üblichen Ratschläge wie "Aufpassen, auf was man klickt" und "Keine verdächtigen Seiten besuchen" helfen gegen die vorgestellten und auch die zu erwartenden zukünftigen Würmer nichts. Die verbreiten sich ohne Interaktion des Benutzers bei dessen Besuch auf einer befallenen, vertrauenswürdigen Seite. Einzig der alte Rat, JavaScript und allgemein aktive Inhalte zu deaktivieren, würde helfen – aber der führt im Web 2.0 nicht mehr weiter, da das auf aktive Inhalte angewiesen ist. Der Benutzer kann nur auf die Schutzfunktionen der Browser (und ggf. Erweiterungen wie Firefoxs NoScript) und Webanwendungen vertrauen.

Bei den Anbietern sieht es ähnlich aus: Die können nur darauf vertrauen, dass die Entwickler der von ihnen eingesetzten Anwendungen keine Schwachstellen übersehen haben (oder das prüfen). Sofern noch nicht berücksichtigt, kann eine Web Application Firewall als zusätzliche Schutzmaßnahme dienen, ansonsten ist es Aufgabe der Webanwendung bzw. deren Entwickler, für die eigene Sicherheit zu sorgen.

Damit bleibt die meiste Arbeit bei den Entwicklern der Webanwendungen. Gegen Webwürmer helfen erst mal die gleichen Maßnahmen wie gegen XSS und CSRF:

• Sorgfältiges Prüfen aller Eingaben – alles, was nicht genau so aussieht, wie es erwartet wird, wird verworfen.
• Wenn HTML zugelassen werden muss, dann nur korrekt formatierte Tags anhand einer Positivliste. Alles, was nicht wohlgeformt ist, könnte in irgendeinem Webbrowser zu unerwünschte Reaktionen führen.
• Schutz aller Funktionen (oder zumindest der jeweils kritischen/sensitiven) vor einer automatisierten Ausführung, z.B. durch Session-Tokens, Prüfen des HTTP-Referers oder Captcha-Systeme. Wobei sich auf den eigenen Seiten ausbreitende Würmer die Session-Tokens ausspähen können, und von der richtigen Seite kommen sie auch meistens.
• iFrames aus verschiedenen (Sub-)Domains für vertrauenswürdige und nicht vertrauenswürdige Bestandteile der jeweiligen Seite würden CSRF und damit einen Wurm ver- oder zumindest behindern, stören aber meist bei der Suchmaschinenoptimierung.
• Immer daran denken: Auch andere aktive Inhalte wie z.B. Flash-Anwendungen können schädlichen Script-Code enthalten!

RSnake hat aus dem Wettbewerb weitere Maßnahmen ermittelt:

• Die Deklaration von onfocus- und onload-Eventhandlern im body-Tag kann Würmer an der Ausbreitung hindern.
• Die Angabe einer DOCTYPE hält die meisten Browser davon ab, Vermutungen über die zu parsenden Daten anzustellen und falsche oder ungewöhnliche Tags zu parsen, und dabei JavaScript-Code auszuführen.

Und wenn es doch passiert?

Sollte sich doch einmal ein Wurm auf dem eigenen Server ausbreiten, ist eine schnelle Reaktion das Wichtigste. Die betroffenen Funktionen müssen vorübergehend stillgelegt, die verwendeten Schwachstellen geschlossen und die gespeicherten Daten vom Wurmcode bereinigt werden.

Beim Beheben von Schwachstellen haben Webanwendungen einen Vorteil gegenüber herkömmlichen Programmen: In dem Moment, in dem eine Schwachstelle in der Webanwendung geschlossen wurde, sind alle Benutzer vor weiteren Angriffen geschützt, und der Wurm ist ausgerottet.

Ab der nächsten Folge geht es um die Suche nach Schwachstellen in Webanwendungen.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Webwürmer"

• About Security #138: Webwürmer (1): Samy, der MySpace-Wurm
• About Security #139: Webwürmer (2): Samys Ende
• About Security #140: Webwürmer (3): Yamanner
• About Security #141: Webwürmer (4): Der Orkut-XSS-Wurm
• About Security #142: Webwürmer (5): Der gemeine Wurm
• About Security #143: Webwürmer (6): Wurmkur