HTML5 Security - Gift für den Application Cache
Nach der Einführung, den XSS-Angriffen und dem Angriff auf Formulare geht es nun um Angriffe auf lokale gespeicherte Daten, konkret die
Daten im Application Cache
Webanwendungen, die auch offline, also ohne Verbindung zum zugehörigen Webserver, funktionieren sollen, speichern die benötigten Dateien im Application Cache. Dazu wird eine Manifest-Datei angelegt, die alle im Application Cache zu speichernden HTML-, JavaScript- und CSS-Dateien, Bilder etc. aufführt. Die Webbrowser werten diese Datei aus und speichern die angegebenen Dateien im Cache, von wo sie dann bei der späteren Offline-Nutzung geladen werden. Der Browser außerdem automatisch dafür, dass die im Cache gespeicherten Dateien aktuell bleiben: Wenn während der Online-Nutzung eine neuere Datei geladen, als im Cache gespeichert ist, wird die Version im Cache durch diese neuere Version ersetzt.
Damit der Browser weiß, dass es eine Manifest-Datei gibt, muss sie in
jeder Seite der Webanwendung im manifest-Attribut des
html-Tags angegeben werden:
<html manifest="/cache.manifest">
Die Manifest-Datei selbst muss den Content-Type
text/cache-manifest haben und kann zum Beispiel so aussehen:
CACHE MANIFEST
/seite1.html
/seite2.html
/JavaScript/script1.js
/JavaScript/bibliothek1.js
/CSS/style.css
/Bilder/Logo.gif
/Bilder/Hintergrund.jpgAußer den zu cachenden Dateien kann die Manifest-Datei bei Bedarf auch Angaben über niemals zu cachende Dateien sowie über Default-Dateien, die an Stelle einer im Cache fehlenden Datei ausgeliefert werden sollen, enthalten.
Gift für den Application Cache
So wie jeder andere Cache kann auch der Application Cache manipuliert werden, genannt Application Cache Poisoning. So einen Angriff hat zum Beispiel Lavakumar Kuppan für Chrome und Safari beschrieben. Das Konzept ist recht einfach:
Opfer und Angreifer nutzen ein ungeschütztes WLAN, zum Beispiel auf einer Konferenz oder in einem Café. Der Angreifer kann dann den Netzwerkverkehr des Opfers belauschen und eigene Antworten einschleusen, bevor der eigentliche Server antwortet. Zum Beispiel könnte der Angreifer dann eine gefälschte Login-Seite für einen Webmail-Anbieter in den Application Cache des Opfers einschleusen. Das Opfer würde dann in Zukunft diese gefälschte Seite verwenden, selbst wenn es das Café längst verlassen hat.
So ein Cache-Poisoning-Angriff läuft folgendermaßen ab:
- Das Opfer ruft
webmail.exampleauf. - Der Angreifer antwortet mit seiner gefälschten Seite, die unter
anderem ein
manifest-Attribut zu einer gefälschtenManifest-Datei enthält, damit die Seite zum Application Cache hinzugefügt wird. - Ruft der Benutzer später zum Beispiel zu Hause erneut
webmail.exampleauf, stellt der Browser fest, dass die Seite im Application Cache gespeichert ist, und gibt sie aus.
Der Cache-Poisoning-Angriff ist sogar möglich, wenn das Opfer die
angegriffene Seite gar nicht aufruft. Es reicht, wenn es irgendeine Seite
aufruft, so dass der Angreifer auf diesen Request mit einer Seite antworten
kann, die einen versteckten iframe mit webmail.example
enthält. Danach geht es wie oben beschrieben weiter.
Application Cache besser als normaler Cache
Ein Angriff auf bzw. über den Application Cache hat für den
Angreifer zwei Vorteile: Zum einen können im Application Cache im
Gegensatz zum normalen Cache auch über HTTPS ausgelieferte Seiten
vergiftet werden (was natürlich einen Angriff auf die
HTTPS-Verschlüsselung erfordert). Im normalen Cache werden diese
Seite nicht gespeichert. Zum anderen wird eine im Cache vergiftete
"Wurzeldatei" (root file) "/" im Fall des normalen Caches
wird diese Seite ersetzt, wenn der Benutzer sie erneut lädt. Im
Application Cache dagegen bleibt sie erhalten.
Das ganze ist etwas vereinfacht, gibt das Grundproblem aber wieder. Tatsächlich sind noch ein paar Kleinigkeiten zu beachten, siehe die Beschreibung des Angriffs von Lavakumar Kuppan. Aber die sind hier uninteressant.
Gegenmaßnahmen
Zu allererst sollte man in unsicheren Netzen möglichst gar keine vertraulichen Daten übertragen. Da sich das nie völlig vermeiden lässt, sollten die Daten, wenn es denn sein muss, nur über verschlüsselte Verbindungen übertragen werden. Das würde in diesem Fall aber nicht zwingend vor dem Angriff schützen, da auch über HTTPS geladene Dateien im Application Cache vergiftet werden können. Dazu muss sich der als Man-in-the-Middle agierende Angreifer jedoch in die SSL-Verbindung einklinken.
Mitunter ist das aber nicht mal nötig: Im Beispiel wird davon ausgegangen, dass die Login-Seite ungeschützt übertragen wird, was leider noch viel zu häufig passiert. Obwohl das unsicher ist und das seit langem bekannt ist. Mittels SSL-Stripping kann ein Man-in-the-Middle dann HTTPS- durch HTTP-Links austauschen, und auch ein Vergiften des Application Caches wäre ihm natürlich möglich. Und das, bevor die HTTPS-Verschlüsselung greift.
Daher ist es generell eine gute Idee, nach der Nutzung eines unsicheren Netzes sämtliche Caches zu löschen - sicher ist sicher. Je nach Browser wird der Application Cache gemeinsam mit dem normalen Cache gelöscht (zum Beispiel in Chrome und Safari) oder muss einzeln gelöscht werden (zum Beispiel in Firefox).
In der nächsten Folge geht es um die Sicherheit des Local Storage. Mehr zum Thema gibt es... aber das haben Sie ja in den bisherigen Folgen oft genug gelesen, und außerdem sind die Cover in der rechten Spalte ja kaum zu übersehen.
Übersicht über alle Artikel zum Thema
- HTML5 Security - Eine Einführung
- HTML5 Security - SVG und Resident XSS
- HTML5 Security - Formulare auf Abwegen
- HTML5 Security - Gift für den Application Cache
- HTML5 Security - Der Local Storage
- HTML5 Security - Die SQL-Datenbank
- HTML5 Security - Cross Origin Requests
- HTML5 Security - Gefährliche WebSockets
- HTML5 Security - postMessage() sicher nutzen
Trackbacks