"Wir setzen voll auf HTML5", sagte Daniel Melanchthon bei der Präsentation des neuen Internet Explorer 9. Der Microsoft-Technologieberater ist überzeugt, dass HTML5 ab sofort für die Neuentwicklung aller wichtigen Webapplikationen zum Einsatz kommen wird.
Nicht nur, weil es Erweiterungen für die Video- und Audiowiedergabe überflüssig macht - Stichwort: Adobe Flash. Auch die verbesserte User-Experience und Performance würden für HTML5 sprechen, so Melanchthon.
Dorothee Ritz, General-Manager Consumer & Online, Microsoft Deutschland, bringt das Anliegen vieler Webentwickler und die Wünsche der Anwender auf den Punkt: "Webanwendungen müssen so laufen wie PC-Anwendungen", so die Managerin während der IE9-Präsentation.
Kein Wunder also, dass Microsoft mit seinem neuen Browser HTML5 unterstützt, genauso wie die Konkurrenten Mozilla (Firefox), Google (Chrome), Apple (Safari) und Opera Software (Opera). Doch wie sieht es mit der Sicherheit des Internet Explorer 9 aus, wenn HTML5-Code ausgeführt wird?
TPL: mehr Sicherheit für die Anwender
Aus den negativen Erfahrungen der Vergangenheit scheint Microsoft eine Menge gelernt zu haben. Jedenfalls bietet der IE9 einige Features, mit denen sich Anwender durchaus sicher fühlen können.
Am wichtigsten dürfte die neue Funktion Tracking Protection List (TPL) sein: Websites, die das Surfverhalten aufzeichnen oder Nutzerdaten einsammeln, lassen sich auf individuelle Sperrlisten setzen.
Der Browser blockiert die Tracking-Dienste und hält sie damit vom Rechner fern. Neben selbst erstellten lassen sich auch vorgefertigte Listen einbinden. Um eine ähnliche Funktionalität in Firefox und Chrome nachzurüsten, sind zusätzliche Erweiterungen notwendig, wie etwa Adblock Plus.
Die Möglichkeit, bestimmte Websites zu blockieren, ist für Anwender im Hinblick auf ein HTML5-Feature von enormer Bedeutung: die lokale Speicherung von Online-Daten auf dem Anwenderrechner. Der Fachbegriff lautet: Client-side storage. Für Webentwickler ist die Neuerung, Applikationsdaten auf dem Client ablegen zu können, vielleicht einer der größten Vorteile von HTML5 - für Anwender kann sie leicht zum Nachteil werden.
Client-side storage - Vor- und Nachteile
Einst zeigten Browser nur die Daten an, die sie vom Webserver vorgegeben bekamen. Schnell erkannten Entwickler die begrenzten Möglichkeiten dieses "Server-Client-Prinzips": Eine Interaktion zwischen Website und Nutzer war kaum möglich. Cookies sollten Abhilfe schaffen. Die kleinen Datenschnipsel werden beim Besuch einer Website ungefragt auf dem Anwenderrechner abgelegt - später senden sie Daten an den Server zurück.
Doch Cookies werden häufig gelöscht oder gleich ganz gesperrt, sind also auch keine gute Lösung. Erst HTML5 erlaubt es Entwicklern, Online-Daten im größeren Stil auf dem Client abzulegen - sieht man einmal davon ab, dass dafür auch Technologien wie Java, Flash oder Silverlight genutzt werden können.
Aus der Client-seitigen Datenspeicherung ergeben sich mehrere Vorteile. Zum Beispiel lassen sich Daten auf verschiedene Art und Weise zwischenspeichern, um sie zu einem späteren Zeitpunkt innerhalb der Webapplikation wieder zu verwenden oder anderen Applikationen zur Weiterverwendung anzubieten. Webanwendungen können dank Client-side storage aber auch vollständig auf dem Client abgelegt werden, sodass sie ohne Internetverbindung nutzbar bleiben.
Leider hat der Anwender kaum Möglichkeiten, das Client-seitige Speichern von Daten zu steuern. In der Regel ist er dem Verhalten der Applikation vollständig ausgeliefert. Da Client-side storage sogar den Zugriff auf die Festplatte des Clients ermöglicht, könnten Angreifer ziemlich leichtes Spiel haben, sowohl Daten der Webapplikation als auch den Anwenderrechner selbst zu manipulieren - sagen jedenfalls einige Experten.
Manche Fachleute befürchten gar, dass Malware-infizierte Daten auf Client-Seite nach Abruf durch den Server diesen ebenfalls infizieren könnten. Fest steht, dass alle Verfahren des Client-side storage einer gründlichen Absicherung bedürfen und im Zweifelsfall nicht für die Speicherung sensibler Daten genutzt werden sollten - zumindest, solange es keine finale Spezifikation des HTML5-Standards durch das W3C gibt.
Client-side storage - die Verfahren
Neben Client-seitigen Datenbanken geht es beim Client-side storage um zwei weitere Verfahrensweisen: die Nutzung des Objekts sessionStorage und des Objekts localStorage. Die einfachere Form des Webspeichers bildet das Objekt sessionStorage. Es legt Daten der aktuellen Session ab - aber nur so lange, wie der Browser geöffnet ist.
Jedes neue Dokument bekommt ein sessionStorage-Objekt zugewiesen, das Basisfunktionen wie setItem, getItem und clear beherrscht. Die Items bestehen aus Schlüssel-Wert-Paaren, vergleichbar mit assoziativen Arrays.
Mehr leistet das localStorage-Objekt. Während sessionStorage vergesslich ist, kann sich localStorage erinnern: Daten bleiben erhalten, obwohl der Browser geschlossen und der Rechner heruntergefahren wird. Und ist eine Website in zwei Fenstern gleichzeitig aktiv, können die lokal gespeicherten Daten sogar gemeinsam genutzt werden. Ändert sich der Code, auf den das eine Fenster gerade zugreift, ändern sich auch die Daten des anderen.
Die Unterstützung des localStorage-Objekts ist in den verschiedenen Browsern noch recht unterschiedlich ausgeprägt, an einer einheitlichen Implementierung arbeiten aber alle Browser-Hersteller.
Sicherheitsaspekte des localStorage-Objekts
Aus Sicherheitssicht gibt es derzeit zwei Hauptprobleme, weshalb Entwickler beim Einsatz des localStorage-Objekts vorsichtig sein müssen:
1. Alle Online-Daten werden auf dem Client unverschlüsselt gespeichert. Das bedeutet: Jeder, der Zugriff auf den Anwenderrechner besitzt, hat theoretisch auch Zugriff auf die Daten.
2. Wie schon erwähnt, bleiben die Online-Daten so lange auf dem Client, bis sie von der Applikation oder vom Nutzer explizit entfernt werden. Im Extremfall also für immer.
Beide Fakten erhöhen die Wahrscheinlichkeit für das Gelingen eines Hacker-Angriffs. Stellen Sie sich beispielsweise vor, Sie betreiben einen Webshop. Sie wollen die Performance der Applikation steigern, indem Sie Daten über getätigte Einkäufe mithilfe des localStorage-Objekts auf dem Client speichern - aus Sicherheitssicht ein Unding.
Der Anwender bemerkt nicht, dass die Daten auch nach Beenden des Browsers auf seiner Festplatte verbleiben. Von dort kann sie theoretisch jeder abgreifen, der Zugang zum Client hat - direkt oder übers Netz. Deshalb sollte das localStorage-Objekt allenfalls für unkritische, öffentliche Daten genutzt werden - für das Speichern sensibler Daten ist es von Haus aus ungeeignet.
Allerdings lässt sich seine Sicherheit deutlich erhöhen. So existieren im Netz verschiedene Vorschläge für APIs, die eine verschlüsselte, sichere Nutzung des localStorage-Objekts ermöglichen sollen. Ein solcher Vorschlag verbirgt sich etwa hinter der Bezeichnung SecureStore 1.0. Die Idee basiert auf drei einfachen Sicherheitsregeln:
-
Nutzerdaten sollten niemals unverschlüsselt gespeichert werden.
-
Der Betreiber der Webapplikation muss den Verschlüsselungsalgorithmus und die zugehörigen Schlüssel selbst kontrollieren können.
-
Auch verschlüsselte Nutzerdaten sollten niemals ewig auf dem Client verbleiben.
Sicherheitsaspekte Client-seitiger Datenbanken
Die professionellste Methode der neuen Webdatenspeicherung sind die Client-seitigen Datenbanken, die HMTL5 implementiert. Damit wird zwischen Web SQL Datenbase und Indexed Database unterschieden.
Letztere Datenbankvariante ist zwar in der Praxis noch wenig erprobt, könnte aber im künftigen HTML5-Standard eine wichtige Rolle spielen.
Doch egal, ob Web SQL oder Indexed Database: Für ausreichend Sicherheit bei der Nutzung müssen die Entwickler sorgen. Ein Entwicklerteam von Google hat auf seinem HTML5-Security-Wiki einige Fragen und Antworten zur Sicherheit Client-seitiger Datenbanken gesammelt, auf die wir an dieser Stelle aus Platzgründen verweisen, ohne weiter auf das noch nicht ganz spruchreife Thema einzugehen.
Kommunikation zwischen Websites
XML HTTP Request (XHR) ist eine API zum Transfer von beliebigen XML-Daten über das Protokoll HTTP. Sämtliche Methoden für HTTP-Anfragen lassen sich verwenden, um mithilfe eines Skripts Daten dynamisch von einem Webserver abzurufen.
Die angezeigte Webseite muss dabei nicht neu geladen werden. Als Skriptsprache kommt in den meisten Fällen JavaScript zum Einsatz, aber auch JScript oder VBScript kann für XHR verwendet werden. XML HTTP Request ist ein wichtiger Grundbestandteil der AJAX-Technik.
Während es andere HTML-Varianten lediglich erlauben, ein XML HTTP Request an den Originalserver der Website zu stellen (Stichwort: Same Origin Policy), gestattet HTML5 die Anfrage an beliebige Webserver, die XHR unterstützen.
Das Verfahren Cross Origin Request (COR) sorgt für jede Menge interessanter Möglichkeiten in der Kommunikation zwischen Websites, birgt aber auch Sicherheitsrisiken, wenn der angefragte Server nicht vertrauenswürdig ist.
Unterschiede zu "crossdomain.xml"
Plug-Ins wie Flash und Silverlight sind ebenfalls in der Lage, ein Cross Origin Request auszuführen. Allerdings unterscheidet sich dieses vom HTML5-COR grundlegend. Bei Flash und Silverlight wird auf dem Server eine Datei "crossdomain.xml" angelegt. Sie verzeichnet, welche Domains CORs stellen dürfen. Wenn Website Nummer eins die Website Nummer zwei in ihrer Datei "crossdomain.xml" erlaubt, kann Website Nummer zwei auf alle Dateien von Website Nummer eins zugreifen. Eine Site hat immer Zugriff auf alle Ressourcen der anderen - oder auf keine.
COR unter HTML5 arbeitet hingegen mit einer auf einzelne Seiten bezogenen Zugriffskontrolle. Jede Seite muss einer anfragenden mit einem bestimmten HTTP-Header antworten, um den Datenzugriff zu gestatten. Damit haben Entwickler die Möglichkeit, nur bestimmten Teilen ihrer Applikation die Kommunikation mit anderen Websites zu erlauben. Die XHR-Steuerung liegt nicht mehr in Händen des Serveradministrators.
Ein weiterer Unterschied: Bei Flash und Silverlight wird die "crossdomain.xml"-Datei vom Browser erst abgeholt und dann analysiert. Wenn einer fremden Website der Zugriff laut "crossdomain.xml" verwehrt ist, verhindert der Browser entsprechende Aufrufe. COR unter HTML5 ruft hingegen erst die externe Seite auf und überprüft dann den HTTP-Header-Eintrag Access-Controll-Allow-Origin.
Sicherheit für Cross Origin Request
Der schlimmste Fehler beim Cross Origin Request ist, beliebigen Websites Zugriff auf die eigene Applikation zu gestatten. Der HTTP-Header Access-Controll-Allow-Origin kann theoretisch auch die Wildcard * enthalten, sollte es aber niemals. Stattdessen müssen immer explizit Domains angegeben werden, um Angreifern nicht Tür und Tor zu öffnen.
Wie schon erwähnt, basiert HTML5-COR auf der Zugriffssteuerung für jede einzelne Webseite. Das hat natürlich auch Nachteile. Wenn ein Entwickler zum Beispiel den Zugriff auf zehn verschiedene Seiten erlaubt, muss er in allen zehn Seiten Änderungen vornehmen, wenn sich die Liste der erlaubten Websites ändert.
Eine Lösung wäre das Erstellen einer Seite, die den COR-Code enthält und per PHP in jede der zehn erlaubten Seiten eingebunden wird:
<?php
if($_SERVER['HTTP_ORIGIN'] == "http://www.diedomain.com")
{
header('Access-Control-Allow-Origin: http://www.diedomain.com');
}
?>
Das Einbinden erfolgt mit include(cor_datei.php). Sicherer wäre es, eine Datenbank zu verwenden, in der die Namen jeder Seite und die erlaubten Websites verwaltet werden.
Zugriffskontrolle je nach Header
Der HTTP-Header-Eintrag Access-Control-Allow-Origin setzt ein gewisses Vertrauen voraus - und wer das nicht richtig einschätzt, kann unter Umständen in Teufels Küche kommen.
Der Header legt nämlich nur fest, dass die HTTP-Anfrage von der festgelegten Domain kommen darf - er garantiert nicht, dass sie es auch tut. Der Zugriff könnte zum Beispiel auch von einem Perl-Skript kommen, das die Original-Domain vortäuscht. Deshalb gilt die eiserne Regel: Nicht authentifizierten Cross Origin Requests sollten Sie niemals vertrauen.
Sobald es um die Übermittlung sensibler Daten geht, sollte die Anfrage unter Verwendung der credentials-Schalter erfolgen. Außerdem muss ein Cookie mit der gültigen Session-ID des Nutzers übertragen werden. Erst nach Prüfung des Cookies darf die COR ausgeführt werden.
Sicher: iFrames mit Sandbox
Zum Glück gibt es auch unumstritten gute Nachrichten in Sachen HTML5-Sicherheit. Sie betreffen zum Beispiel das iframe-Tag, das eine externe Seite innerhalb der eigenen Webpräsenz aufruft.
Bisher konnten iframe-Bereiche relativ einfach manipuliert werden - in HTML5 sorgt das neue Attribut sandbox dafür, dass dies ungleich schwieriger wird. Mittels sandbox können im iframe Festlegungen getroffen werden, was erlaubt ist und was nicht.
<iframe sandbox="allow-same-origin">...</iframe>
Damit wird geregelt: Obwohl auf der Website generell Scripting erlaubt ist, gilt dies nicht für den Bereich der Sandbox. Die eingebundene Website wird aber im DOM berücksichtigt.
<iframe sandbox="allow-top-navigation">...</iframe>
Bei dieser Einschränkung kann in den Webseiten innerhalb des iframe-Bereichs navigiert werden. Eine Ausweitung der Navigation auf die übergeordnete Webseite ist hingegen nicht möglich.
<iframe sandbox="allow-forms">...</iframe>
Dieses Attribut erlaubt keine Übertragung von Formulardaten innerhalb der Sandbox.
<iframe sandbox="allow-scripts">...</iframe>
Bei diesem Attribut wird im Sandbox-Bereich das Scripting nicht erlaubt, wenn mindestens eine der nachfolgenden Bedingungen unerfüllt bleibt:
-
Der User-agent unterstützt Scripting.
-
Der Nutzer hat für diese Webseite das Scripting zugelassen.
-
Die Webseite hat kein Flag für Scripting in der Sandbox. Diese
Bedingung gilt für den Moment, in dem die Webseite im Browser aufgebaut wird.
Fazit
Wenn es um HTML5 und Sicherheit geht, gibt es noch hohen Klärungsbedarf. Schon jetzt tauchen viele Fragen auf, bei denen Experten noch uneins sind.
Insbesondere die lokale Speicherung von Daten auf Client-Seite und der Datenaustausch zwischen mehreren Servern werden derzeit heiß diskutiert - wir haben die Problematik hier nur kurz skizziert, sie ist weitreichender und tiefgründiger.
Auf dem Weg zur Standardisierung von HTML5 werden sich wahrscheinlich etliche weitere Fragen ergeben, die die Sicherheit des künftigen Standards betreffen. Unterdessen setzen wir diese Praxisreihe mit einem dritten Teil zum Thema Stabilität von HTML5 fort. (mje)