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

</a onmousemove="alert(1)">

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:

<video src="..." onerror="alert(1)">

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:

echo "<input type=\"text\" value=\"".$input."\">";

Mit der Eingabe

" autofocus onfocus=alert(1) "

ergibt das in der Ausgabe

<input type="text" value="" autofocus onfocus=alert(1) "">

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