Die dunkle Seite des neuen Webstandards

HTML5 aus Hackersicht
Kommentare

HTML5 bringt neue Möglichkeiten – für Webentwickler und für Angreifer:
Woran denken Sie, wenn von HTML5 die Rede ist? Sicher an die vielen schönen Funktionen und Fähigkeiten, die neue Webanwendungen ermöglichen. Aber wissen Sie auch woran Hacker dabei denken? – An neue und verfeinerte Angriffe! Dieser Artikel wirft einen Blick auf Sicherheitslücken in HTML5 und zeigt, wie Hacker diese für sich ausnutzen können.

HTML5 gibt es als Standard noch gar nicht und wird es als Standard zumindest vorerst auch nicht geben. Stattdessen wird es als „Work in Progress“ ständig Änderungen darin geben. Trotzdem enthalten die Browser schon mehr oder weniger viele Features davon.

Neue Tags und APIs, lokale Datenspeicher und Cross-Origin Requests erlauben die Entwicklung interessanter Webanwendungen, lassen sich aber auch für bösartige Zwecke nutzen. Folgen Sie mir auf eine Reise zur „dunklen Seite“ von HTML5 und erfahren Sie, wie Cyberkriminelle HTML5 missbrauchen können. In der nächsten Folge erfahren Sie dann, wie Sie zumindest einen Teil dieser Angriffe verhindern können.

Artikelserie

Teil 1: Die dunkle Seite des neuen Webstandards
Teil 2: HTML5-Angriffe verhindern

HTML5 und Cross-Site Scripting (XSS)

Auf der Heft-CD finden Sie den Artikel „Cross-Site Scripting – Angreifers Leatherman“ aus dem PHP User-Magazin 1.2010. Die darin beschriebenen Angriffe basieren alle auf HTML vor HTML5. Die neuen Tags und geänderten Attribute etc. für altbekannte Tags führen zu neuen Einfallstoren. Dazu kommen die neuen Funktionen, die natürlich auch für bösartige Zwecke missbraucht werden können.

Aber konzentrieren wir uns erst einmal auf die neuen Möglichkeiten zum Einschleusen von XSS-Code [1, Verweise auf der Heft-CD]. Fangen wir mit den schließenden Tags an, die bisher immer harmlos waren. Im Grunde konnte eine Funktion zum Erkennen oder Ausfiltern von XSS-Angriffen beim Erkennen von überspringen, da an dieser Stelle kein JavaScript eingeschleust werden konnte. Das ist nun anders: Ein entsprechend implementierter Filter würde ein Tag, wie z. B. akzeptieren und dadurch einem XSS-Angriff Tür und Tor öffnen.

XSS für Augen und Ohren

Finden Sie die neuen audio– und video-Tags auch extrem nützlich? Dann passen Sie auf, dass Ihnen niemand darüber XSS-Code einschleust! Wenn Sie das Tag z. B. durch den Code echo „ erzeugen, müssen Sie darauf achten, dass $url wirklich ein URL ist bzw. keinen XSS-Code enthält. Denn eine Eingabe wie

http://website.example/link/zu/keinem/video.mpg" onerror="alert(1)

würde in der Ausgabe zu <audio src="http://website.example/link/zu/keinem/video.mpg“ onerror=“alert(1)“> und damit XSS führen.


Auf den kommenden Seiten erwarten euch…:

  • Autofocus, Autofeuer
  • Jeder macht, was er will
  • SVG ist eine Grafik?
  • XSS-Einfallstore ohne Ende
  • Vorsicht auch bei der Abwehr!
  • Lokaler Speicher, globales Problem
  • 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 -