© saicle/Shutterstock.com
HTML5-Angriffe verhindern: Den neuen Webstandard sicher einsetzen

HTML5, aber sicher!


HTML5 birgt neben schönen neuen Möglichkeiten auch viele Sicherheitslücken, die Hacker für sich ausnutzen können. In diesem Artikel erfahren Sie, wie Sie solche Angriffe verhindern oder zumindest erschweren können, und wie Sie HTML5 allgemein sicher einsetzen.

Wie Cyberkriminelle HTML5 missbrauchen können, haben Sie im PHP Magazin 3.2012 gelesen. Dieser Artikel orientiert sich am Aufbau des ersten Teils, sodass Sie ggf. leicht nachschlagen können, welche Angriffe im Zusammenhang mit den jeweils beschriebenen Funktionen etc. drohen. Los geht es daher auch wieder mit Cross-­site Scripting (XSS), diesmal aber aus „Verteidigersicht“.

XSS-Angriffe abwehren

Wie Sie XSS-Angriffe abwehren, wissen Sie ja sicher schon. Mit HTML5 kommen nur weitere mögliche Angriffe hinzu, sodass Sie ggf. ihre White- oder Blacklist des Öfteren überprüfen und an die neuen Gegebenheiten anpassen müssen. Eine Liste bekannter Angriffe stellt das HTML5 Security Cheatsheet [1] bereit. Aber HTML5 bringt nicht nur neue Angriffe, sondern auch eine neue Schutzmaßnahme: iframes im Sandkasten.

iframes im Sandkasten

Das sandbox-Attribut von HTML5 ermöglicht es, per iframe eingebundene Inhalte in ihren Möglichkeiten zu beschränken [2], [3]. Per Default wird der Inhalt des ­iframes bei gesetztem sandbox-Attribut so behandelt, als käme er von einem fremden Origin. Es ist kein Zugriff auf das DOM der einbettenden Seite, die Cookies oder den Local Storage möglich, und das Ausführen von JavaScript-Code und Plug-ins sowie das Verwenden von Formularen wird verhindert. Einige Einschränkungen können bei Bedarf einzeln aufgehoben werden. Das Attribut kann vier Werte annehmen:

  • allow-same-origin: Der Inhalt des iframes wird so behandelt, als stamme er aus dem Origin der einbettenden Seite und nicht aus einer anderen.

  • allow-top-navigation: Der Inhalt des iframes darf den Top-Level-Kontext ändern.

  • allow-forms: Der Inhalt des iframes darf Formulare verwenden.

  • allow-skripts: Skripte im iframe werden ausgeführt, es dürfen aber keine Pop-ups geöffnet werden.

Wenn Sie allow-scripts und allow-same-origin gleichzeitig verwenden, gibt es u. U. eine unerwünschte Nebenwirkung, wenn eingebundene und einbindende Seite den gleichen Origin haben: Die eingebundene Seite kann das sandbox-Attribut entfernen.

Browser mit und ohne iframe-Sandbox

Das sandbox-Attribut wird natürlich nur von Browsern berücksichtigt, die es kennen. Zurzeit sind das die auf WebKit basierenden Browser, wie Apples Safari und Google Chrome. Der Internet Explorer wird das Attribut ab Version 10 unterstützen, die Firefox-Entwickler sind ebenfalls bereits mit der Implementierung beschäftigt. Browser, die das sandbox-Attribut nicht unterstützen, binden den Inhalt ohne jede Einschränkung ein. Möchten Sie, dass eine möglicherweise bösartige Seite nur in einer Sandbox eingebunden wird, können Sie mit dem Code aus Listing 1 prüfen, ob der verwendete Browser das Attribut unterstützt.

Listing 1

if ("sandbox" in document.createElement("iframe")) {  // Das sandbox-Attribut wird unterstützt }

Kein Licht ohne Schatten

Auch das eigentlich sehr nützliche sandbox-Attribut hat einen unschönen Nebeneffekt, der sich negativ auf die Sicherheit von Webanwendungen auswirkt. Sie haben ihn im ersten Teil des Artikels bereits kennengelernt: Wenn über das sandbox-Attribut die Top-Level-Navigation ausgeschaltet wird, ist ein zur Abwehr von Clickjacking-Angriffen eingesetzter Framebuster wirkungslos. Die einzige bekannte Schutzmaßnahme gegen Clickjacking-Angriffe ist damit der X-FRAME-OPTIONS HTTP Header.

Der X-FRAME-OPTIONS HTTP Header

Über den X-FRAME-OPTIONS Header in der HTTP-Response kann gesteuert werden, wie sich die Seite in einem Frame verhalten soll [4]. Der Header wurde zuerst im Internet Explorer eingeführt, inzwischen wird er auch in Firefox [5], Chrome [6], Safari [7] und Opera [8] unterstützt. Er kann folgende Werte annehmen:

  • DENY: Der Browser stellt die Seite grundsätzlich nicht dar, wenn sie in einem Frame geladen wird.

  • SAMEORIGIN: Die Seite wird nur dann in Frames dargestellt, wenn der Top-Level-Kontext vom gleichen Origin wie die Seite stammt.

Microsoft hat noch einen weiteren Wert vorgesehen: ­ALLOW-­FROM origin bedeutet die Seite wird nur dann in Frames dargestellt, wenn der Top-Level-Kontext vom Origin origin stammt. Dieser Wert wird aber nicht von allen Browsern unterstützt.

Lokal speichern, aber sicher!

Im ersten Teil haben Sie erfahren, wie verlockend die Daten im lokalen Speicher, egal ob Session, Local Storage oder Web-SQL-Datenbank, für die Angreifer sind. Sie müssen sich also sehr gut überlegen, welche Daten Sie überhaupt auf dem Client speichern wollen, und wie Sie dafür sorgen, dass sie dort möglichst sicher sind.

Der Session Storage

Im Session Storage können je nach Browser fünf bis zehn MB Daten pro Domain für die Dauer einer Session gespeichert werden. Beim Schließen des Browserfensters bzw. Beenden des Browsers wird der Session Storage gelöscht [9]. Die Daten sind darin relativ sicher, für Zugriffe gilt die Same Origin Policy: Auf die Daten darf nur aus dem zugehörigen Dokument (d. h. im Grunde dem zugehörigen Fenster bzw. Tab) zugegriffen werden, und der Zugriff ist an das jeweilige Protokoll, die Domain und den Port gebunden. Das schützt zwar nicht vor einem Zugriff über Cross-site Scripting, aber dem evtl. schädlichen JavaScript-Code in anderen Browserfenstern oder Tabs ist der Zugriff auf die Daten versperrt.

Löschen ist wichtig

Im Fall des Session Storage müssen Sie nur ein mögliches Problem berücksichtigen, das sich am besten an einem Beispiel erklären lässt: Ein Webportal enthält u. a. eine Webmail-Anwendung, die die angezeigten E-Mails im Session Storage speichert. Ein Benutzer loggt sich in einem Tab im Webportal ein und öffnet nacheinander mehrere E-Mails. Parallel liest er in einem anderen Tab Nachrichten im Webportal und loggt sich danach in diesem Tab aus. Dabei bleiben die Daten im anderen Tab im Session Storage gespeichert. Wechselt der Benutzer in das Tab mit der Webmail-Anwendung, kann er die bereits geöffneten E-Mails weiter lesen, ohne eingeloggt zu sein. Das wird zum Problem, wenn ein Rechner von mehreren Benutzern genutzt wird, z. B. in einem Internet-Café oder einer Bibliothek: Schließt der Benutzer das Fenster bzw. den Tab mit der Webmail-Anwendung nicht, kann ein späterer Benutzer auf die im Session Storage gespeicherten E-Mails zugreifen.

Um zu verhindern, dass auf die Daten im Session Storage auch nach dem Ausloggen zugegriffen werden kann, muss der aktuelle Status des Benutzers vor jeder Aktion geprüft werden. Dazu können Sie einen Cookie verwenden, in dem der aktuelle Status gespeichert wird. Nach dem Einloggen wird der Wert dieses Cookies zusammen mit dem aktuellen Datum und der Uhrzeit im Session Storage gespeichert. Bei jedem späteren Zugriff wird dieser Wert mit dem aktuellen Wert des Cookies verglichen. Cookies sind für alle Fenster und Tabs identisch und werden dynamisch aktualisiert. Wenn sich der Benutzer in einem Tab oder Fenster ausloggt und dabei der Cookie gelöscht oder sein Wert geändert wird, ist dies sofort auch in a...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang