Suchen

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.

Firma 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.

(ID:42304348)