Shortcuts - HTML5 Security - HTML5 Security


Preis: k.A.

Erhältlich ab:  Mai 2012

Autoren / Autorinnen: Shortcut Autorenteam

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.

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang