HTML5 aus Hackersicht
Kommentare

XSS-Einfallstore ohne Ende
Dies ist nur eine kleine Auswahl möglicher XSS-Angriffe unter HTML5. Eine lange, aber sehr wahrscheinlich trotzdem nicht vollständige Liste möglicher Angriffe enthält das

XSS-Einfallstore ohne Ende

Dies ist nur eine kleine Auswahl möglicher XSS-Angriffe unter HTML5. Eine lange, aber sehr wahrscheinlich trotzdem nicht vollständige Liste möglicher Angriffe enthält das HTML5 Security Cheat Sheet [3]. So ein Angriff funktioniert zwar nicht immer unbedingt in allen Browsern, aber im Allgemeinen finden Cyberkriminelle immer genug Opfer.

Und im Fall eines gezielten Angriffs werden sowieso erst alle nötigen Informationen gesammelt und dann der Angriff gestartet. Und wenn dabei XSS zum Einsatz kommen soll, gehört dann eben auch der verwendete Browser zu den „nötigen Informationen“.

Vorsicht auch bei der Abwehr!

Die einfachste Möglichkeit XSS-Angriffe abzuwehren, ist eine Whitelist zulässiger Eingaben, insbesondere natürlich in Verbindung mit einem totalen HTML/JavaScript-Verbot in der Eingabe. Oder möglicher XSS-Code wird durch rigoroses Umkodieren, vor allem natürlich der , unbrauchbar gemacht (was auch nicht immer gelingt, s. o.).

Aber meist möchte man in Zeiten des Web 2.0 ja gerade HTML oder auch JavaScript erlauben, und das wird durch HTML5 komplizierter. Insbesondere alle Schutzmaßnahmen, die mit Blacklists arbeiten, sind in HTML5 unterstützenden Browsern (und welcher halbwegs aktuelle Browser unterstützt HTML5 nicht?) über eine ganze Reihe neuer Vektoren angreifbar und müssen laufend an die neuen Entwicklungen angepasst werden. Aber auch die generell deutlich sicherere Lösung mit einer Whitelist zulässiger Eingaben muss laufend aktualisiert werden, wie das Beispiel der Attribute in schließenden Tags verdeutlicht.

Einem Angreifer kommt dabei das altbekannte „Never touch a running system“ zu Gute: Wann haben Sie denn das letzte Mal die Schutzmaßnahmen einer älteren Webanwendung aktualisiert? Oder auch nur angesehen?

Lokaler Speicher, globales Problem

Die prominenteste der neuen Funktionen dürfte der als Local Storage oder Web Storage bezeichnete lokale Speicher für Anwendungsdaten auf dem Client sein. Darin können je nach Browser fünf bis zehn Megabyte Daten pro Domain als Key-Value-Paare dauerhaft gespeichert werden.

Mit dem Local Storage vergleichbar ist der Session Storage, in dem die Speicherung aber auf die Session-Dauer beschränkt ist. Daher gilt das im folgenden über den Local Storage gesagte auch immer für den Session Storage. Mit der Einschränkung, dass eine Session läuft und darin Daten gespeichert sind, während die Daten im Local Storage solange erhalten bleiben, bis sie gezielt gelöscht werden. Für einen Angreifer hat der lokale Speicher zwei Vorteile: Zum einen kann er u. U. auf die darin gespeicherten Daten zugreifen, zum anderen kann er eigene Daten darin speichern.


Auf den kommenden Seiten erwarten euch…:

  • Der Spion im Browser
  • Client vs. Server
  • War da was?
    Beispiel Session-ID
  • SQL-Injection-Angriff auf den Client
  • Gefahren für die Clientdatenbank
  • Hartnäckiger XSS-Wurmbefall
  • Lokal gespeicherter Schadcode
  • Cross-Origin Requests
  • Ein kleiner Abstecher: Clickjacking
  • Clickjacking the Like-Button = Likejacking
  • Clickjacking + HTML5 = Neue Angriffsmöglichkeiten
  • Ein praktischer Angriff: Cookiejacking
  • iframe: Sandkasten gegen JavaScript
  • Schöne neue Funktionen, schöne neue Möglichkeiten
  • Info zum Autor Carsten Eilers
  • Links und Literatur
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -