Alles andere als ausgezeichnet HTML5 bietet neue Angriffsflächen

Autor / Redakteur: Michael Matzer / Stephan Augsten

HTML5 ist zwar eine leistungsfähige Entwicklungsgrundlage für flexible Client-seitige Web-Applikationen, bietet jedoch auch neue Angriffsflächen. Auf einer Sicherheitskonferenz, die Mitte Mai in San Francisco stattfand, zeigte eine Security-Expertin sowohl die Schwachstellen als auch geeignete Gegenmaßnahmen.

Firmen zum Thema

Einige neue HTML5-Funktionen sind anfällig und werden bereits von Hackern ausgenutzt.
Einige neue HTML5-Funktionen sind anfällig und werden bereits von Hackern ausgenutzt.
(Bild: Sergey Mavrody / Wikipedia)

Viele Browser unterstützen bereits HTML5, obwohl die offizielle Freigabe durch das W3C (World Wide Web Consortium) noch aussteht. Die neueste Version der Auszeichnungssprache bietet eine Reihe von Funktionen, um die Erstellung von interaktiven Mashup-Applikationen für das Web zu vereinfachen.

Merkmale wie iFrame-Sandboxing, Programmierschnittstellen für XMLHttpRequest und Web Storage, quellenübergreifendes Teilen von Ressourcen sowie erweiterte Markup-Möglichkeiten sind Merkmale einer leistungsfähigen Client-seitigen Entwicklungsumgebung.

Bildergalerie
Bildergalerie mit 8 Bildern

Aufgrund der neuen Funktionen bietet die jüngste Version des De-facto-Standards zur Webseiten-Entwicklung aber auch einige Angriffsflächen. Prajakta Jagdale, eine Security-Expertin bei HP Fortify Software Security Research, hat die HTML5-basierten Sicherheitslücken mit teils bekannten Angriffsmethoden konfrontiert.

Cross-Site Request Forgery

Schutzmaßnahmen gegen Cross-Site Request Forgery (CSRF), dem Fälschen von Anfragen unterschiedlicher Sites mithilfe verschleierter Token, lassen sich mitunter völlig nutzlos machen. Hierfür können sich Cyberkriminelle besipielsweise die Funktion des quellenübergreifenden Teilens von Ressourcen (Cross-Origin Resource Sharing, CORS) zunutze machen.

Mit CSRF erschleichen sich Angreifer höhere Benutzerrechte, um so eine falsche Identität mit entsprechenden Zugriffsrechten vorspiegeln zu können. Man muss also die Verschleierung der Tokens beseitigen, um den wahren Ursprung des Tokens mit dem vorgespiegelten „legitimen“ Ursprung vergleichen zu können.

Unterschieden sich die Herkunftsangaben, liegt eine Fälschung durch CSRF vor. Header-Angaben helfen laut der Jagdale zwar, als besser geeignete Sicherheitsmaßnahme empfählen sich aber Einmal-Token.

Clickjacking

Angreifer können das Feature des iFrame ausnutzen, um Abwehrmaßnahmen gegen Clickjacking zu umgehen, die von herkömmlichen HTML-Anwendungen verwendet werden. Clickjacking spielt beim CSRF eine wichtige Rolle.

Dabei wird der Nutzer dazu überlistet, eine gefälschte Webseite zu nutzen, die in einem unsichtbaren iFrame dargestellt wird. Der Nutzer kann also den Unterschied zwischen „echt“ und „gefälscht“ nicht erkennen, gibt daher nichtsahnend sein Passwort ein.

Das Sandboxing von iFrames muss deshalb laut Jagdale vom legitimen Entwickler von vornherein implementiert werden. Außerdem muss er X-Frame-Optionen nutzen, um sich gegen Cross-Frame-Attacken („Frame-busting“) zu schützen; zudem ist der deklarative Sicherheitsansatz zu nutzen, der von allen verbreiteten Browsern unterstützt wird.

Eine Umfrage ergab jedoch das niederschmetternde Ergebnis, dass von 100.000 in Alexa gelisteten Webseiten nur 4.600 die genannten Schutzmaßnahmen verwendeten. Gut ein Drittel (38 Prozent) der Sites nutzen die neue X-Frame-Option, 62 Prozent hingegen die alte, anfällige Möglichkeit.

XHR

Die API XMLHttpRequest (XHR) wird bereits missbraucht, um CSRF vollständig zu automatisieren, wodurch wiederum der Einsatz von Clickjacking-Techniken überflüssig wird. „Get“-Requests sind das Ziel. Der sicherheitsbewusste Entwickler muss verbieten, dass vorhandene Formularelemente modifiziert werden. Das Umgehen von Tokens gegen CSRF erforderte bislang die Interaktion mit dem Opfer.

CORS

Die Funktion des quellenübergreifenden Teilens von Ressourcen (Cross-Origin Resource Sharing, CORS) macht nach Ansicht der Expertin Prajakta Jagdale die Ausnutzung von CSRF zu einem „Kinderspiel“ („piece of cake“). Die Domain-übergreifende Kommunikation, die CORS erlaubt, lässt sich im Hinblick auf Zugriff und Nutzereingaben ausnutzen und erfordert lediglich die clevere Anwendung der Befehle PUT, SEND, POST und DELETE. „Ein entsprechendes Request-Script hat vollen Zugriff auf den Inhalt der Nutzerantwort“, beklagte Jagdale.

Um Abhilfe zu schaffen, müsse die CORS-Funktion von der Ziel-Anwendung bzw. ihrem Server freigegeben werden. Nur so ließen sich Policies durchsetzen, und Policies kann der Verantwortliche mit Hilfe entsprechender HTTP-Response-Header steuern.

Local Storage

Die Web-Storage-API bietet Möglichkeiten, auf dem Client Inhalte zu speichern. Aber wenn diese Lokation nicht angemessen geschützt oder konfiguriert wird, bieten sie dem Angreifer Einfallstore, um vertrauliche Daten zu stehlen. Local Storage ist also eine Sache des Datenschutzes, wenn dabei Benutzername und Passwort im Klartext abgelegt werden.

Bei Cookies mag das ja noch angehen, solange sie am Ende der Sitzung gelöscht werden, aber was ist, wenn ein Browser oder Request „unlimited storage“ verlangt? Jagdale führte Google Chrome als Bösewicht in dieser Hinsicht an. Eine Technik, die laut der Expertin niemals genutzt werden sollte, ist jQuery, laut Wikipedia eine der verbreitetsten Java-Bibliotheken im Web, etwa um AJAX-Apps zu entwickeln. Seit April 2013 gibt es jQuery 2.0, das Internet Explorer 6 bis 8 nicht mehr unterstützt.

Offline-Applikationen

HTML5 unterstützt auch Anwendungen, die vorübergehend offline gehen können (etwa in Chrome) und dabei im Cache des Browsers eine Ladeliste („manifest“) ablegen. Darin stehen interessante Dinge wie Skriptnamen, Dateinamen und vieles mehr. Jagdale befiehlt aus Gründen des Datenschutzes: „Do! Not! Cache!“ Der Cache lässt sich nämlich auch quasi „vergiften“, also manipulieren, um etwa eine Denial-of-Service-Attacke zu starten. Abhilfe schaffe die regelmäßige Auffrischung des Offline-Caches, um so alte oder gefährliche Inhalte zu löschen.

Einfallstor Markup

Auf der Markup-Seite erweitern neue Tags und Attribute die Angriffsfläche von Anwendungen, die sich noch auf Blacklisting als Schutz gegen Cross-Site-Scripting (XSS), eine der häufigsten Angriffsmethoden, verlassen. Laut Jagdale lassen sich mit folgenden Tags und Attributen solche Filter leicht umgehen, indem man sie als Injektionsvektoren missbraucht:

• onerror

• oninput

• input

- onfocus

- onblur

- autofocus

• body

- onscroll

- autofocus

• button

- onforminput

- onformchange

Ein entsprechender Spickzettel findet sich auf html5sec.org. Auf diesem Spickzettel (cheat sheet) sind die anfälligen Browser-Versionen aufgelistet sowie Vorbeugungsmaßnahmen erläutert. Der Entwickler sollte sie möglichst beherzigen.

(ID:42304348)