Dipl.-Inform. Carsten Eilers

Was HTML5 genau ist, weiß niemand. Und kann auch niemand wissen. Denn HTML5 als Standard ist "Work in Progress", und das gleich von zwei Seiten, denn W3C und WHATWG gehen getrennte Weg. Und was HTML5 als Implementierung betrifft - auch das ist "Work in Progress", die Browserentwickler implementieren HTML5 nach Lust und Laune, fügen auch mal Neues hinzu, lassen dafür anderes weg, und was in einem Browser funktioniert, muss im anderen nicht unbedingt genau so funktionieren. Wenn es denn überhaupt funktioniert.

Das von so einem Durcheinander natürlich auch die Angreifer profitieren, dürfte klar sein.

HTML5 - Fast schon ein Betriebssystem?

In der Einführung zur HTML5-Beschreibung des W3C finden wir den folgenden Satz (Hervorhebung von mir):

"1.3 Scope:
[...]
The scope of this specification is not to describe an entire operating system. [...]"

Nun, man entwickelt vielleicht kein vollständiges Betriebssystem, aber verdammt nah dran ist HTML5, wenn ich mir so ansehe, was da alles dazu gehört: Dateisystem API, WebSockets API, Fullscreen API, Zugriff auf Webcam und GPS-Sensor, ... . Da fehlt nicht viel zu einem vollständigen Betriebssystem. Sie kennen sicher den alten Spruch über den Editor Emacs: "Emacs is a great operating system – it lacks a good editor, though." ("Emacs ist ein großartiges Betriebssystem – allerdings fehlt ihm ein guter Editor."). Auch HTML5 ist bald ein tolles Betriebssystem. Was fehlt? Vielleicht ein Webbrowser?

Aber mal Spass beiseite, der Vergleich hat einen ernsten Hintergrund: HTML5 kann unheimlich viel, aber diese vielen Möglichkeiten bringen auch viel Verantwortung mit sich. Entwickler von Webclients haben mit HTML5 mehr oder weniger die gleichen Möglichkeiten wie die Entwickler von Desktop-Anwendungen. Ist ihnen aber auch bewusst, dass sie damit die gleichen Verpflichtungen haben, ihre Anwendungen sicher zu entwickeln?

Das gleiche gilt natürlich entsprechend auch für die Browser-Entwickler - die entwickeln nicht mehr nur irgend eine Desktop-Anwendung, sondern im Grunde etwas, was einem Betriebssystem ähnelt. Ob sie mit dieser Verantwortung richtig umgehen, wage ich zu bezweifeln. Dazu aber später mehr.

HTML5 ist riesig und unübersichtlich

Werfen wir noch einmal einen Blick in die Einführung des W3C:

"1.5 Design notes
[...]
It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent.
[...]"

HTML5 ist auf den ersten Blick unsinnig und inkonsistent? Auch auf dem zweiten und jeden weiteren Blick wird das nicht unbedingt sehr viel besser. Was zum nächsten Problem führt: Um etwas sicher entwickeln bzw. implementieren zu können, benötigt man klare Spezifikationen in einem beherrschbaren Umfang. Beim W3C ist HTML5 als einzelne HTML-Seite 4,4 MB gross, bei der WHATWG 6.1 MB. Noch Fragen? Dann stellen Sie die W3C und WHATWG, die haben sich das ausgedacht!

Aber kommen wir jetzt zum eigentlichen Thema: Der Sicherheit von HTML5. Los geht es mit Cross-Site Scripting. Einfach, weil das zu HTML5 nun mal dazu gehört.

XSS - HTML5 macht's möglich(er)!

Die erste Folie zum Thema XSS habe ich mit "Neue Tags, neue Attribute, neue Angriffe" überschrieben, und das ist auch schon das Hauptproblem: Es gibt viele neue Möglichkeiten für XSS-Angriffe, auf die alte Webanwendungen einfach nicht eingerichtet sind. Die haben jetzt unter Umständen XSS-Schwachstellen, wenn sie über einen HTML5-fähigen Browser genutzt werden. Und welcher Browser unterstützt HTML5 nicht?

Mal ein paar Beispiele. Los geht es mit Attribute in schließenden Tags, etwas, was es bisher nicht gab. Falls ein XSS-Filter beim Erkennen von </ alles bis zum nächsten >-Zeichen ignoriert, weil dort ja kein JavaScript eingeschleust werden kann, kann er jetzt durch ein Tag wie

ausgetrickst werden. Wann haben Sie denn das letzte Mal die Schutzmaßnahmen alter Anwendungen überprüft? Oder auch nur angesehen? "Never touch a running system!", nicht wahr?

Als Beispiel für neue Tags dürfen die video- und audio-Tags dienen:

spielt kein Video, sondern öffnet eine Alertbox.

Auch immer wieder nett: XSS mit Autofokus. Bei Kameras nützlich, im Browser zumindest in diesem Fall eher ärgerlich. Nehmen wir mal an, Ihre Webanwendung enthält folgenden Code:

Mit der Eingabe

ergibt das in der Ausgabe

und damit eine sich öffnende Alertbox.

Ist Ihnen an der Eingabe etwas aufgefallen? Sehen Sie mal genau hin! Der XSS-Angriff kommt ohne < und > aus. Sollte Ihr XSS-Schutz darin bestehen, diese potentiell gefährlichen Zeichen auszufiltern oder in HTML-Entities umzuwandeln, ist er in diesem Fall unwirksam. Und das, ohne das Sie irgend etwas getan hätten. Es reicht, dass die Benutzer einen HTML5-fähigen Browser verwenden.

Eine lange Liste über HTML5 möglicher XSS-Angriffe finden Sie im HTML5 Security Cheatsheet.

In der nächsten Folge geht es mit dem Thema "HTML5 Sicherheit" weiter.

Carsten Eilers

Übersicht über alle Artikel zum Thema

HTML5 Security - Eine Einführung

HTML5 Security - SVG und Resident XSS

HTML5 Security - Formulare auf Abwegen

HTML5 Security - Gift für den Application Cache

HTML5 Security - Der Local Storage

HTML5 Security - Die SQL-Datenbank

HTML5 Security - Cross Origin Requests

HTML5 Security - Gefährliche WebSockets

HTML5 Security - postMessage() sicher nutzen