HTML5 Security

Von Carsten Eilers

HTML5 ist nicht nur die neueste Version von HTML, sondern umfasst auch CSS und eine Vielzahl von JavaScript-APIs. Damit lassen sich sehr mächtige Webclients entwickeln, aber auch Cyberkriminelle profitieren von den neuen Möglichkeiten. Egal ob Cross Origin Requests, WebSockets oder WebSQL-Datenbank, ob Session oder Local Storage, alle neuen Funktionen erlauben auch neue Angriffe auf und über sie. Wenn Sie diese Angriffe bei der Entwicklung nicht berücksichtigen, wird früher oder später ein Angreifer die entstandenen Schwachstellen finden und ausnutzen. Genau darum geht es in diesem shortcut: Welche neuen Angriffe sind möglich und wie können sie verhindert werden?

Übrigens: Auch wenn Sie in Ihrer Webanwendung kein HTML5 einsetzen, müssen Sie aufpassen. Und wussten Sie schon, dass die bisher zum Schutz vor Clickjacking eingesetzten Framebuster in HTML5 vom sandbox-Attribut für iframes ausgehebelt werden und dann wirkungslos sind?

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 4. Mai 2012
• ISBN: 9783868024173

Buchvorschau

Carsten Eilers

HTML5 Security

ISBN: 978-3-86802-417-3

© 2012 entwickler.press

Ein Imprint der Software & Support Media GmbH

Vorwort

HTML5 gibt es als Standard noch gar nicht und wird es als Standard zumindest vorerst auch nicht geben. Stattdessen wird es als Work in Progress ständig Änderungen daran geben. Trotzdem enthalten die Browser schon mehr oder weniger viele Features davon. Neue Tags und APIs, lokale Datenspeicher, Cross Origin Requests, WebSockets und Co. erlauben die Entwicklung interessanter Webanwendungen, lassen sich aber auch für bösartige Zwecke nutzen. In diesem Buch geht es um letzteres: Wie können Angreifer HTML5 für ihre Zwecke missbrauchen und viel wichtiger: Wie können Sie als Entwickler diese Angriffe verhindern oder zumindest erschweren?

Die Angriffsziele

Wenn man Angriffe abwehren will, ist die erste Frage immer Was will der Angreifer erreichen? Im Fall der Clients von Webanwendungen gibt es darauf sowohl praktische als auch theoretische Antworten. Fangen wir mit den praktischen an. Zur Zeit gibt es zwei Arten von Angriffen, die weit verbreitet sind:

Im Rahmen von sog. Drive-by-Infektionen wird JavaScript-Code in die Webanwendungen und dadurch in die Clients eingeschleust, der dann sog. Exploits nachlädt, mit denen Schwachstellen im Webbrowser oder dessen Plugins ausgenutzt werden. Der Webclient dient dabei nur als Einfallstor: Nachdem ein Exploit nachgeladen wurde, nutzt der z.B. eine Pufferüberlauf-Schwachstelle im Flash Player aus, um Schadcode im System des Benutzers zu verankern. Danach hat der JavaScript-Schadcode seine Schuldigkeit getan und wird beendet.

Webwürmer nutzen den Client, um sich über ihn in der Webanwendung zu verbreiten. Früher geschah das i.A. über Cross-Site Scripting, heute kommt oft Clickjacking zum Einsatz. Egal welche Methode die Angreifer einsetzen, der Client ist nur der Weg zum Ziel: Wenn ein Benutzer eine vom Wurm bereits befallene Seite, z.B. das Social-Network-Profil eines anderen Benutzers, aufruft, dringt der Wurm über den Browser des Benutzers in dessen Profilseite ein. Früher reichte den Angreifern die bloße Verbreitung des Wurms, inzwischen wird parallel oft auch noch heimlich Werbung angeklickt, so dass die Cyberkriminellen auch finanziell vom Wurm profitieren.

Dann gibt es noch die theoretischen Angriffe:

Ein Angreifer, der den Webclient und damit den Webbrowser unter seiner Kontrolle hat, befindet sich im lokalen Netz und damit hinter der Firewall. Hier kann er nun nach weiteren interessanten Zielen suchen, wofür ihm z.B. ein mit JavaScript realisierter Portscanner zur Verfügung steht. Ob es solche Angriffe auch in der Praxis gibt, ist nicht sicher. Im Rahmen von Massenangriffen sind sie bisher nicht aufgefallen (sie wären dafür wohl auch eher ungeeignet), ob sie im Rahmen gezielter Angriffe zum Einsatz kommen, hat bisher niemand verraten. Die Opfer solcher Angriffe halten sich natürlich mit Informationen darüber, wie sie hereingelegt wurden, zurück, und die Angreifer haben erst Recht keine Veranlassung, ihre Methoden zu verraten.

Ein weiteres mögliches Angriffsziel wurde auf dem 28. Chaos Communication Congress (28C3) Ende Dezember 2011 von Artur Janc vorgestellt: Ein Angreifer, der einen Webclient unter seine Kontrolle bringt, kann darüber alle Aktionen der Webanwendung ausführen, die auch der normale Benutzer ausführen darf. Warum sollten die Angreifer also mühsam die meist gut geschützte Webanwendung auf dem Server angreifen, wenn sie doch genau so gut den oft weniger gut geschützten Webclient angreifen und darüber auf die Webanwendung zugreifen können? Auch dies sind bisher theoretische Überlegungen. O b es wirklich einmal entsprechende Angriffe in the wild geben wird, bleibt abzuwarten.

In die gleiche Richtung zielt ein weiterer, schon länger diskutierter Angriff: Je intelligenter die Clients werden und je mehr von der Business Logic der Webanwendung auf den Client ausgelagert wird, desto interessanter wird der für den Angreifer. Eine Manipulation des Clients hat dann direkte Auswirkungen auf den Benutzer und die Webanwendung: Der Benutzer wird zu Aktionen verleitet, die er gar nicht ausführen will, bzw. der eingeschleuste Schadcode führt selbst Aktionen in seinem Namen aus. Ein eher schlechtes Beispiel ist in diesem Zusammenhang das Onlinebanking, das über Schadcode auf dem Client-Rechner angegriffen wird. Diese sog. Man in the Browser-Angriffe zeigen jedoch, was ein Angreifer über die Manipulation des Clients erreichen kann.

Angriffe wird es immer geben

Aber egal ob Theorie oder Praxis: Generell muss eine sichere Anwendung allen möglichen Angriffen widerstehen. Grundsätzlich gilt: Alles, was Sie einsetzen, um Ihren Benutzern zu nützen, missbrauchen die Angreifer ggf., um Ihnen und Ihren Benutzern zu schaden. Wenn Sie wissen, welche Gefahren drohen, können Sie den Angreifern dabei das Leben so schwer wie möglich machen. Und wie Sie das beim Einsatz von HTML5 erreichen, ist das Thema der folgenden Kapitel.

1 XSS, JavaScript & Co.

In diesem Kapitel dreht sich alles um Cross-Site Scripting, JavaScript und Ähnliches. Das DOM-basierte Cross-Site Scripting gewinnt immer mehr an Bedeutung, und mit Resident XSS bekommt HTML5 seine eigene XSS-Variante. Weitgehend unabhängig von der Art des XSS erlauben die neuen Tags und Attribute in HTML5 neue Angriffe. Aber es gibt auch zumindest eine gute Nachricht: Das sandbox-Attribut für iframes kann beim Einbinden nicht vertrauenswürdiger Inhalte XSS-Angriffe zumindest erschweren.

1.1 Cross-Site Scripting

Als Cross-Site Scripting (kurz XSS) wird das Einschleusen von bösartigem JavaScript- oder HTML-Code in eine Webseite bezeichnet. Die klassischen Varianten des XSS kennen Sie sicher:

Beim reflektierten XSS wird der Schadcode an die Webanwendung gesendet und von dieser ungeprüft an den Client zurückgeschickt. Für den Angriff muss das Opfer einen präparierten Link anklicken oder ein präpariertes Formular abschicken, in dem der Schadcode enthalten ist (Abbildung 1.1).

Ein klassisches Beispiel war immer die Suchfunktion der Websites: Der gesuchte Begriff wird ungeprüft und ungefiltert auf der Ergebnisseite ausgegeben, beispielsweise nach dem Muster

Ihre Suche nach SUCHBEGRIFF ergab folgendes Ergebnis:

Bei Eingaben wie Hund, Katze, Maus ... passiert genau das, was sich der Entwickler dabei gedacht hat. „Sucht" aber jemand nach dem klassischen XSS-Beispiel

öffnet sich die Alert-Box: Der eingeschleuste JavaScript-Code wird ausgeführt.

Abbildung 1.1: Reflektiertes