Full paper - Fachbereich Informatik

Transcription

Sicherheitsanalyse von
HTML5
Bachelor-Thesis von Markus Heinrich
18. Oktober 2012
Fachbereich Informatik
Sicherheit in der Informationstechnik
Sicherheitsanalyse von HTML5
Vorgelegte Bachelor-Thesis von Markus Heinrich
Prüfer: Prof. Dr. Michael Waidner
Betreuer: Martin Stopczynski, M.Sc.
Tag der Einreichung:
Erklärung zur Bachelor-Thesis
Hiermit versichere ich, die vorliegende Bachelor-Thesis ohne Hilfe Dritter nur mit den angegebenen
Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus Quellen entnommen wurden, sind
als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, den 16. Oktober 2012
(Markus Heinrich)
I
Zusammenfassung
HTML 4.01 wurde 1999 veröffentlicht. Durch die rasante Entwicklung des Internets wurde HTML mit der Zeit den
Anforderungen einer modernen Webanwendung nicht mehr gerecht. Seit 2004 arbeitet die WHATWG und das W3C an
dem Nachfolger, HTML5. Mittlerweile haben sich die wichtigsten Teile des neuen Standards stabilisiert und sind nur noch
geringfügigen Änderungen unterworfen. Diese Arbeit stellt die neuen Schnittstellen in HTML5 vor und analysiert ihren
Einfluss auf die Sicherheit von Webanwendungen. Das beinhaltet Angriffsvektoren und Sicherheitsrisiken, die Entwickler
bei der Implementierung verhindern und schließen können.
Dazu werden die Alexa TOP 10.000 Webseiten auf HTML5 und seine APIs untersucht und eine Nutzungsstatistik
erstellt, die auch die sichere Verwendung von HTML5 betrachtet.
II
Inhaltsverzeichnis
Zusammenfassung
II
Abbildungsverzeichnis
V
Tabellenverzeichnis
VI
Quelltextverzeichnis
VII
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
2 Grundlagen
2.1 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 W3C und WHATWG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
6
3 Neue Elemente in HTML5
3.1 Web Messaging . . . . . . . . . . . . . . .
3.1.1 Spezifikation . . . . . . . . . . . .
3.1.2 Anwendung . . . . . . . . . . . . .
3.1.3 Sicherheitsaspekte . . . . . . . . .
3.2 Web Worker . . . . . . . . . . . . . . . . .
3.2.1 Spezifikation . . . . . . . . . . . .
3.2.2 Anwendung . . . . . . . . . . . . .
3.3 Das keygen Element . . . . . . . . . . . .
3.3.1 Spezifikation . . . . . . . . . . . .
3.3.2 Anwendung . . . . . . . . . . . . .
3.4 Web Storage . . . . . . . . . . . . . . . . .
3.4.1 Spezifikation . . . . . . . . . . . .
3.5 Cross-Origin Resource Sharing . . . . . .
3.5.1 Spezifikation . . . . . . . . . . . .
3.6 WebSocket API . . . . . . . . . . . . . . . .
3.6.1 Spezifikation . . . . . . . . . . . .
3.7 Offline Web Applications . . . . . . . . . .
3.7.1 Spezifikation . . . . . . . . . . . .
3.8 Weitere Elemente und Angriffsvektoren
3.8.1 Event-Handler . . . . . . . . . . .
3.8.2 Server-Sent Events . . . . . . . . .
3.8.3 History API . . . . . . . . . . . . .
3.8.4 Associated Form . . . . . . . . . .
3.8.5 Geolocation API . . . . . . . . . .
3.8.6 IFrame Sandbox und Seamless .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
9
9
10
12
14
14
15
16
18
18
18
20
20
22
26
26
27
29
29
30
32
32
33
36
36
36
37
37
38
38
4 Nutzungsanalyse
4.1 Aufbau . . . . . . . .
4.1.1 Downloader
4.1.2 Scanner . .
4.2 Ergebnis . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
40
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III
5 Fazit
46
5.1 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Abkürzungsverzeichnis
49
Literaturverzeichnis
52
Anhang
57
A Chat mit Anne van Kesteren
58
IV
Abbildungsverzeichnis
1.1 HTML5 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2.1 Logos der Arbeitsgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
Vergleich Kommunikation mit HTML . . . . . . . . . . . .
Weiterleiten des Port Objektes . . . . . . . . . . . . . . . .
Facebook Connect Schema [18] . . . . . . . . . . . . . . .
Web Worker . . . . . . . . . . . . . . . . . . . . . . . . . . .
SharedWorker mit drei Browserkontexten (vereinfacht)
attacker.com instanziiert Worker . . . . . . . . . . . . . .
Opera Zertifikatsverwaltung . . . . . . . . . . . . . . . . .
Badoo.com: Kommunikation zwischen Fenstern . . . . .
Cross-Directory Angriff . . . . . . . . . . . . . . . . . . . . .
Opera benötigt mehr LocalStorage . . . . . . . . . . . . .
opera:webstorage . . . . . . . . . . . . . . . . . . . . . . .
CORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Browser bitten um Erlaubnis für Application Cache . . .
Konfiguration des Anwendungsspeichers . . . . . . . . . .
Nutzung der Geolocation API im Firefox . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
11
12
14
15
16
19
22
22
23
24
27
34
34
38
4.1
4.2
4.3
4.4
Anteil Nutzung HTML5 nach Rang . . . . . . . . . .
„Gefällt Mir“-Button auf stylebook.de . . . . . . . . .
Anteile Web Storage . . . . . . . . . . . . . . . . . . .
Unsichere Nutzung von CORS und Web Messaging
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
43
44
44
.
.
.
.
.
.
.
.
.
.
.
.
V
Tabellenverzeichnis
2.1 Browserversionen und Marktanteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Unterstützung Web Messaging . . . . . . .
Unterstützung Workers und WebWorkers .
Algorithmen für das keygen-Element . . .
Unterstützung Web Storage . . . . . . . . .
Größe des Web Storage . . . . . . . . . . .
Unterstützung CORS . . . . . . . . . . . . .
Unterstützung WebSockets . . . . . . . . .
Unterstützung Offline Web Applications .
Unterstützung der weiteren Technologien
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
9
15
18
20
23
26
29
32
36
4.1 Vorkommen der HTML5 Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
VI
Quelltextverzeichnis
2.1 HTML Grundgerüst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
Aufrufe der postMessage()-Methode . . . . . . . . . . . . . . . . . . .
MessageChannel und Versenden eines Ports . . . . . . . . . . . . . . .
Empfangen eines Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event-Listener mit Sender-Kontrolle . . . . . . . . . . . . . . . . . . . .
Worker im Benutzerkontext . . . . . . . . . . . . . . . . . . . . . . . . .
Kontext des Workers (worker.js) . . . . . . . . . . . . . . . . . . . . . .
SharedWorker von fremder Domain: JavaScript auf attacker.com .
SharedWorker: Benutzerkontext . . . . . . . . . . . . . . . . . . . . . .
worker.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASN.1 Definition des übertragenen öffentlichen Schlüssels . . . . . .
Verwendung des keygen-Elements . . . . . . . . . . . . . . . . . . . . .
Feststellen des privaten Modus mit LocalStorage . . . . . . . . . . . .
globalStorage Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auflistung aller Elemente im localStorage . . . . . . . . . . . . . . . .
Browserquest Speicherdatum . . . . . . . . . . . . . . . . . . . . . . . .
CORS Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client Handshake [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Handshake [13] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwendung des WebSockets . . . . . . . . . . . . . . . . . . . . . . . .
Verwendung des Manifestes . . . . . . . . . . . . . . . . . . . . . . . . .
manifest.appcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Cache Beispiele . . . . . . . . . . . . . . . . . . . . . . . . .
HTML5 Event-Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . .
Angriff mit dem form-Attribut . . . . . . . . . . . . . . . . . . . . . . .
Frame Busting [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
10
10
10
12
14
14
16
17
17
18
18
21
21
23
24
26
29
29
30
32
32
33
36
38
39
4.1 User-Agent Header des Crawlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
VII
1 Einleitung
Abbildung 1.1: HTML5 Logo
Die Hypertext Markup Language (HTML) ist seit über 20 Jahren die Grundlage beim Erstellen von Webseiten. Sie ist
das zentrale Element im bekanntesten Teil des Internets, dem World Wide Web. Mit Version 5 befindet sich nun der Nachfolger der 1999 vorgestellten Version 4.01 in der Entwicklung, mit dem Ziel den Anforderungen des modernen Internets
gerecht zu werden. Diese Anforderungen haben sich seit der ersten Webseite 1989, von einer rein wissenschaftlichen
Plattform hin zu einem Alleskönner entwickelt, in dem heute leicht Informationen gesucht oder veröffentlicht werden
können. Auch die kommerzielle Welt setzt mehr und mehr auf das Internet und bietet eine Vielzahl an Produkten und
Dienstleistungen online an. Mit der zunehmenden Leistungsfähigkeit der privaten Computer und Notebooks wird der
Browser auch für Spieleentwickler interessant, die höhere Ansprüche an die Grafik-Performanz stellen, als eine einfache
Webseite. Die Anforderungen beschränken sich jedoch nicht nur auf die grafische Oberfläche, sie erfordern auch neue
Kommunikationswege im Hintergrund und mehr Schnittstellen zum Betriebssystem, um moderne Webseiten zu gestalten. All diese Aspekte nehmen Einfluss auf die Entwicklung von HTML und den dazugehörigen JavaScript-Schnittstellen.
Bei der Gestaltung der fünften Version des Standards darf aber auch die Sicherheit nicht aus den Augen gelassen werden.
Schwachstellen müssen gefunden und behoben werden, um Angreifern die Grundlage ihrer Angriffe zu nehmen.
1.1 Motivation
In den letzten zehn Jahren hat sich der Anteil der Internetnutzer weltweit auf etwa 33 % vervierfacht [22]. Längst sind
die Anwender keine professionellen Computernutzer oder Wissenschaftler mehr, stattdessen bilden sie einen Querschnitt
durch die Bevölkerung. In Industrieländern nutzen sogar drei von vier Personen das Internet [22]. Sie suchen nach
Informationen oder nutzen das Web zum Zeitvertreib. Aber auch geschäftliche Dinge werden über das Internet erledigt,
so nutzen 44 % der Deutschen bereits Online Banking [9] und der deutsche Versandhandel macht zwei Drittel seines
Umsatzes über das Internet [8]. Damit das Surfen im World Wide Web für die breite Masse der Nutzer sicher bleibt, ist es
wichtig beim Design von HTML51 und seinen Schnittstellen darauf zu achten bereits vorhandene Lücken zu schließen und
keine neuen zu öffnen. Eine Studie hat gezeigt, dass Webseiten von Banken durchschnittlich 17 Sicherheitslücken jährlich
aufweisen, bei Webseiten des Einzelhandels sind es sogar 121 [16]. Solche Schwachstellen können dazu führen, dass
Angreifer die Kontrolle über ein Benutzerkonto übernehmen können, oder an sensible, private Informationen gelangen
und damit Schaden anrichten. Durch HTML5 kann diese Angriffsfläche verringert werden. Allerdings können auch die
sicheren Features in unsicherer Weise verwendet werden, weshalb in dieser Arbeit Risiken und mögliche Fallstricke
aufgezeigt werden und wie man sie verhindern kann. Dazu müssen die spezifizierten neuen Funktionen kritisch betrachtet
werden, um Lücken aufzudecken und Lösungen zu ihrer Schließung aufzuzeigen.
Viele Teile der HTML5-Spezifikation sind bereits so weit vorangeschritten, dass schon Implementierungen existieren.
Während die Zahl dieser Implementierungen übersichtlich bleibt, da es nur wenige marktrelevante Browser gibt, ist die
Quantität der tatsächlichen Verwendung auf Webseiten schwer zu bestimmen. Verschiedene Quellen sind sich noch nicht
1
HTML Version 5
1
einmal über die absolute Anzahl der Webseiten einig. Eine Abschätzung liefert die Anzahl, der von Suchmaschinen indizierten Webseiten. Diese betrug 2005 etwa 11,5 Milliarden Seiten [17]. Dazu kommt der Teil des Internets, der nicht von
Suchmaschinen erfasst ist und sich daher nicht abschätzen lässt. Um heraus zu finden, welche Elemente der Spezifikation
wie häufig verwendet werden, werden die 10.000 meist besuchten Webseiten des Alexa-Rankings [1] auf die Nutzung
von HTML5 untersucht. Dadurch kann festgestellt werden, wie weit sich HTML5 bereits im Internet durchgesetzt hat. Es
ist nicht nur interessant, das Vorkommen an sich zu beziffern, sondern ob die Verwendung möglicherweise auf unsichere
Art geschieht und eine Angriffsfläche darstellt. Für die vorgestellten Risiken wird daher analysiert, ob sie sich in realen
Implementierungen wiederfinden.
1.2 Organisation
Diese Arbeit ist wie folgt organisiert. Nachdem in Kapitel 2 zunächst einige Grundlagen und historischen Aspekte erläutert
werden, sollen in Kapitel 3 die neuen Elemente von HTML5 vorgestellt werden. Diese sind:
1. Web Messaging – Eine Schnittstelle zur Kommunikation mit anderen Kontexten und den Web Workern
2. Web Worker – Paralleles Ausführen von JavaScript, ähnlich dem Threading
3. Das keygen Element – Schnittstelle zur Generierung von asymmetrischen Schlüsselpaaren im Browser
4. Web Storage – Der Anwendungsspeicher stellt eine Schlüssel-Wert Schnittstelle zum Abspeichern von Daten bereit
5. Cross-Origin Ressource Sharing ermöglicht die Kommunikation über die Same-Origin-Policy hinaus
6. WebSocket API – Ein Duplex-Kanal zwischen Client und Server
7. Offline Web Applications definieren, welche Teile einer Webanwendung auch ohne Internetverbindung verfügbar
sein sollen
8. Event Handler – Neue Möglichkeiten, JavaScript auszuführen
9. Server-Sent Events – Nachrichten von der Serverseite empfangen
10. History API – Manipulieren des Verlaufes, um Änderungen durch XHR2 zu repräsentieren
11. Associated Form – Formularelemente über die gesamte Seite verteilen
12. Die Geolocation API übermittelt die Position des Gerätes an die Webseite
13. IFrame Sandbox und Seamless – Kontrolle über das Aussehen und den Inhalt der eingebetteten Seite
Für jedes der aufgelisteten Elemente wird auf die wichtigen Eigenschaften der Spezifikation eingegangen und einige
Anwendungsfälle vorgestellt. Anschließend werden sicherheitsrelevante Aspekte diskutiert.
In Kapitel 4 wird ein Crawler beschrieben, der analysiert, welche der Elemente bereits verwendet werden. Danach
werden die Ergebnisse der Analyse vorgestellt. Kapitel 5 zieht ein Fazit, stellt verwandte Arbeiten vor und gibt einen
Ausblick.
2
2
XMLHttpRequest
2 Grundlagen
HTML1 wurde 1989 von Tim Berners-Lee am CERN2 entwickelt, um die dort gewonnenen wissenschaftlichen Erkenntnisse leichter für alle Mitarbeiter zugänglich zu machen. Seitdem folgten bis HTML 4.01 im Jahr 1999 verschiedene
Versionen, die nicht mehr ausschließlich wissenschaftlichen Zwecken dienten und mit unterschiedlichsten Inhalten dem
World Wide Web zu seiner Bekanntheit und Verbreitung verhalfen.
HTML strukturiert beliebigen Text durch so genannte Tags, die in spitzen Klammern (<>) eingeschlossen werden, wie
in Listing 2.1 zu sehen. Um Verwechselungen zu vermeiden, wird synonym auch von Elementen gesprochen.
Der Browser parst ein HTML-Dokument und erstellt aus dem Markup das DOM3 , einen objektorientierten Baum der
Elemente und ihrer APIs4 . Das DOM kann durch diese APIs manipuliert werden, wodurch die heute verbreitete Dynamik
von Webseiten ermöglicht wird.
1
2
3
4
5
6
7
8
9
<! doctype html >
<html >
<head >
<title >Ein HTML Dokument </title >
</head >
<body >
Inhalt
</body >
</html >
Listing 2.1: HTML Grundgerüst
Browser
Der Browser ist für den Anwender das wichtigste Mittel zur Benutzung des World Wide Web. Er sendet die Anfragen an
den Webserver, lädt die angeforderten Informationen herunter und stellt sie gemäß dem enthaltenen Markup dar. Dafür
werden hauptsächlich die Sprachen HTML, JavaScript und CSS5 verwendet, die ein Browser in die grafische Darstellung
umsetzen muss.
Die am häufigsten verwendeten Browser sind Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Opera und
Apple Safari. Die weltweiten Marktanteile werden regelmäßig von Net Applications [33] und StatCounter [42] veröffentlicht. Wie in Tabelle 2.1 zu erkennen, unterscheiden sich die Anteile, aufgrund unterschiedlicher Zählweisen [21],
jedoch deutlich. Gemeinsam haben beide, dass Chrome, Firefox und Internet Explorer die verbreitetsten Browser sind,
gefolgt von Opera und Safari, die auf Platz vier und fünf nur geringen Marktanteil besitzen. Diese fünf Browser stellen
die Grundlage der Betrachtung in dieser Arbeit dar. Die übrigen Browser, von denen StatCounter 139 auflistet, besitzen
zusammen genommen nur einen Anteil von etwa 2 % [42].
In Tabelle 2.1 werden auch die Browserversionen zu Beginn und Ende der Bearbeitungszeit dieser Arbeit dargestellt.
Die getroffenen Aussagen beziehen sich, soweit nicht anders angegeben, auf diese Versionen, wobei meist kein Unterschied der Versionen in Bezug auf HTML5 besteht.
Browser
Version
Start
Ende
Chrome
Firefox
Internet Explorer
Opera
Safari
18
12
9
11.64
5.1
21
15
9
12
6
Marktanteil
Statcounter Net Applications
34 %
23 %
33 %
2%
7%
19 %
20 %
54 %
2%
5%
Tabelle 2.1: Browserversionen und Marktanteile
Im Zusammenhang mit Browsern wird auch der Begriff Browserkontext (verkürzt: Kontext) verwendet. Ein Browserkontext wird für jedes heruntergeladene und dargestellte Dokument erzeugt, er schützt den Inhalt durch die SOP6 und
seine APIs vor Zugriffen und hält in seinem Inneren weitere APIs, wie das DOM, bereit.
1
2
3
4
5
6
4
Hypertext Markup Language
http://www.cern.ch
Document Object Model
Application Programming Interfaces
Cascading Style Sheets
Same-Origin-Policy [38]
Alle modernen Browser unterstützen das Browsen in so genannten Tabs, bei dem mehrere Webseiten gleichzeitig in
verschiedenen Registerkarten betrachtet werden können. Man kann sich einen solchen Tab als Visualisierung eines Kontextes vorstellen, genau wie jedes weitere geöffnete Browserfenster. Allerdings ist ein Kontext nicht immer von einem
anderen unterscheidbar, da sie durch eingebettete Frames (IFrame), für die ein neuer Kontext erstellt wird, auch verschachtelt werden können. Wenn im Folgenden von einem (Browser-) Kontext gesprochen wird, ist relevant, dass ein
Kontext den Schutz zwischen den Origins, welche im Folgenden erklärt werden, sicherstellt und die Schnittstellen der
Interaktion bereithält.
2.1 Sicherheit
Es werden nun, als Grundlage der Sicherheit im Web, die Same-Origin-Policy wichtige Schutzziele beim Design von Web
Anwendungen und die häufigsten Angriffe auf Webanwendungen vorgestellt.
Same-Origin-Policy
Die Same-Origin-Policy (SOP) spielt eine wichtige Rolle bei der Absicherung von Webseiten gegen Cross-Site Scripting
Angriffe. Sie wurde 1996 von Netscape eingeführt und regelt den Zugriff auf das DOM. Später wurde sie auch auf
Cookies, Plugins, wie Flash und Java, und XHRs ausgeweitet [73].
Für den Zugriff unter der SOP wird der so genannte Origin des Objektes, auf das zugegriffen wird (Ziel), und der des
Zugreifenden (Quelle) verglichen. Ein Origin setzt sich aus den drei Teilen Protokoll, Host und Port zusammen:
• Protokoll – Das Protokoll, mit dem der Zugriff stattfinden. Hier meist HTTP7 oder HTTPS8 .
• Host – Der Name des Hosts. Beispielsweise example.com. Der eventuell folgende Pfad ist nicht relevant.
• Port – Der Port. Hier 80 (HTTP) oder 443 (HTTPS).
Sollte einer der drei Teile für Quelle und Ziel verschieden sein, ist der Zugriff unter der SOP verboten [28]. So war
es zunächst nicht möglich, beispielsweise Bilder von einer fremden Domain einzubinden. Da dies zu streng war, wurden
Ausnahmen für die SOP definiert, die es ermöglichen, vermeintlich sichere Inhalte auch von anderen Domains zu laden.
Solche Inhalte sind neben Bildern Stylesheets und JavaScript-Dateien. Allerdings sind diese Dokumente nur vermeintlich
sicher, da auch hier Angriffe gefunden werden konnten [6]. Ein Beispiel ist der CSRF9 -Angriff auf Wikipedia [71], bei
dem ein Benutzer unbefugt ausgeloggt werden kann. Der Angriff wird erst durch die Ausnahmen der SOP ermöglicht.
Aber auch die beschriebenen Ausnahmen genügen nicht mehr den Anforderungen an moderne Webseiten, sodass mit
dem in Abschnitt 3.5 beschriebenen Cross-Origin Ressource Sharing weitere, kontrollierte Ausnahmen zur SOP geschaffen wurden. Die SOP trennt, wie in Abbildung 3.1 gezeigt, zunächst zwei Domains voneinander ab. Durch die Ausnahmen
sind allerdings auch Cross-Domain Anfragen mit HTTP und HTTPS möglich (gepunktete Linie HTTP(S) in Abbildung 3.1).
Die zusätzlichen Möglichkeiten durch CORS10 sind durch die hinzugekommenen Pfeile in Abbildung 3.1b im Vergleich
zu 3.1a erkennbar. Einige neue Technologien, wie der Web Storage (Abschnitt 3.4), sind weiterhin durch die SOP geschützt. Andere, wie die Server-Sent Events (Abschnitt 3.8.2) und die WebSockets (Abschnitt 3.6), erlauben durch CORS
gesicherte Ausnahmen der SOP.
Obwohl Origin durch die SOP definiert und ein deutlich präziserer Begriff als Domain ist, werden beide Begriffe im
Folgenden synonym verwendet. Meist ist für Origin dabei jedoch die schwächere Bedeutung Domain ausreichend. Bezüge
auf die SOP gehen aus dem Zusammenhang hervor.
Schutzziele
Einige der vorgestellten neuen Elemente von HTML5 erfordern die Definition und Einhaltung von Schutzzielen, da
diese von kritischen Anwendungen, wie Online-Banking oder Webmail, benötigt werden. Die Einhaltung der Schutzziele soll die Sicherheit des Benutzers einer Webanwendung gewährleisten und verhindern, dass Angreifer an sensible
Informationen gelangen oder gar verfälschen können.
7
8
9
10
HyperText Transfer Protocol
HyperText Transfer Protocol Secure
Cross-Site Request Forgery [35]
Cross-Origin Resource Sharing
5
Die Schutzziele sind:
• Vertraulichkeit – Der Inhalt einer Nachricht ist ausschließlich dem Sender und Empfänger bekannt und kann nicht
von einem Dritten im Klartext gelesen werden.
• Integrität – Die Nachricht wurde auf dem Weg vom Sender zum Empfänger nicht verändert. Für eine Verletzung
der Integrität muss ein Angreifer nicht zwingend den Inhalt einer Nachricht kennen.
• Authentizität – Die Nachricht stammt (nachweisbar) sicher von dem angegebenen Sender.
Um die Ziele zu erreichen, kommen bei HTML5 verschiedene Technologien zum Einsatz. Darunter befinden sich Verschlüsselung und Prüfsummen, aber auch die korrekte Implementierung des Browsers.
Angriffe
Das „Open Web Application Security Project“ (OWASP) veröffentlicht regelmäßig die TOP 10 der kritischsten Sicherheitsrisiken in Webanwendungen [72]. Die aktuelle Liste von 2010 enthält zwei Angriffsvektoren, die besondere
Bedeutung im Bezug auf HTML5 besitzen:
A2 Cross-Site Scripting (XSS) ermöglicht einem Angreifer, Code auf einer Webseite einzuschleusen und auszuführen.
Dabei unterscheidet man, ob der Code bei jeder Anfrage an den Webserver injiziert werden muss (reflektiert), oder
ob es dem Angreifer gelingt, ihn vom Server automatisch ausliefern zu lassen (persistent). Siehe dazu [36].
A5 Als Cross-Site Request Forgery (CSRF) wird bezeichnet, wenn es einem Angreifer gelingt ohne Wissen seines
Opfers eine Anfrage vom Browser des Opfers an einen Webserver zu schicken. Da hier meist Zugangsinformationen
automatisch übertragen werden, hat der Angreifer die Möglichkeit, gesicherte Aktionen im Namen seines Opfers
auszuführen. Siehe dazu [35].
Bei der Entwicklung von HTML5 wurde besonders darauf geachtet, für diese Angriffe keine neue Fläche zu schaffen,
da sie – wie die OWASP TOP 10 zeigen – die häufigsten Angriffe gegen Webanwendungen darstellen.
2.2 W3C und WHATWG
(a) W3C
(b) WHATWG
Abbildung 2.1: Logos der Arbeitsgruppen
Das World Wide Web Consortium (W3C) wurde 1994 von Tim Berners-Lee gegründet, um der Spaltung des Internets
in einen kommerziellen und akademischen Bereich entgegen zu wirken. Das W3C11 veröffentlichte daraufhin neben
verschiedenen Versionen von HTML auch andere wichtige Standards, die das Internet geprägt haben.
Nach der Erscheinung von HTML 4.01 im Jahr 1999 geriet die weitere Entwicklung jedoch ins Stocken, worauf 2004
die Web Hypertext Application Technology Working Group (WHATWG) von den Browserherstellern Mozilla, Opera und
Apple gegründet wurde. Die WHATWG12 beschäftigte sich fortan mit der Weiterentwicklung von HTML, bis das W3C
2006 eine Arbeitsgruppe einrichtete, die eine Kopie des WHATWG HTMLs zu HTML5 weiterentwickeln sollte.
Seit 2007 arbeiten beide Arbeitsgruppen gemeinsam parallel an ihren Spezifikationen. Allerdings verfolgen die Arbeitsgruppen verschiedene Philosophien bei der Entwicklung des Standards.
Die WHATWG sieht die Spezifikation als „Living Standard“, der insbesondere keine Versionierung besitzt und daher
als HTML bezeichnet wird – ohne Versionsnummer. Der „Living Standard“ drückt dabei aus, dass sich HTML stetig
weiterentwickelt und den Anforderungen von Browserherstellern, Webentwicklern und Internetbenutzern anpasst. Die
11
12
6
World Wide Web Consortium [64]
Web Hypertext Application Technology Working Group [68]
Elemente der Spezifikation besitzen dafür Zustände von „First draft“, für erste Notizen und Vorschläge für den Standard,
bis „Implemented and widely deployed“, für bereits verwendbare Teile der Spezifikation.
Das W3C arbeitet auf eine Art Schnappschuss des Standards hin, dem HTML5, der nach Veröffentlichung stabil bleibt.
Um die Stabilität schneller erreichen zu können, wurden Teile des Standards vom W3C in eine eigene Spezifikation
ausgelagert, so beispielsweise die Web Worker. Das W3C hat daher den Zustand „Working Draft“ für Teile, die noch
größeren Änderungen unterlegen sein können, festgelegt. Als „Candidate Recommendation“ werden Teile markiert, die
sich nur in Details verändern können und daher für Implementierungen geeignet sind [57]. Alle vorgestellten Teile
befinden sich aktuell in einem der beiden Zustände. Der Übergang zum fertigen Standard, der „Recommendation“, ist für
das Jahr 2022 geplant [66]. Nach Aussage von Michael Smith vom W3C könnte es aber auch schon im Jahr 2016 soweit
sein [24]. Eine abgespeckte Version könnte bereits 2014 erscheinen [20].
Der Hauptautor beider Spezifikationen war Ian Hickson, bis er im Juli 2012 also Autor des W3C zurücktrat, um sich
auf die WHATWG zu konzentrieren [19, 63].
Die Spezifikationen sind weiterhin bis auf wenige Teile identisch. Unterschiede werden in [49] aufgezeigt. Bei identischer Spezifikation wird auf die des W3C verwiesen. Sollten relevante Unterschiede bestehen, so wird darauf hingewiesen.
Außerdem werden im Folgenden HTML und HTML5 synonym verwendet. Andere Versionen von HTML oder Ausnahmen sind angegeben oder gehen aus dem Kontext hervor.
7
3 Neue Elemente in HTML5
(a) Kommunikation vor HTML5
(b) Kommunikation mit HTML5
Abbildung 3.1: Vergleich Kommunikation mit HTML
Bei HTML 4 war die Kommunikation mit dem Webserver klar begrenzt. Die SOP schirmte, bis auf einige Ausnahmen,
die Domains voneinander ab (siehe Abbildung 3.1a). Dazu ging jegliche Kommunikation immer von der Clientseite aus.
Ein Server konnte keine Nachricht an die Clients schicken, die gerade die Webseite geöffnet haben. Denn HTTP ist
ein zustandsloses Protokoll; kein Server weiß, ob sich ein Benutzer noch auf seiner Seite bewegt. Neue Informationen
konnten nur auf Anfrage des Clients übertragen werden, oder man setzte Plugins, wie Flash, ein. Eine Kommunikation
zwischen verschiedenen Browserkontexten auf Clientseite war gar nicht vorgesehen.
Durch HTML5 kommen neue standardisierte Kommunikationswege hinzu, nachdem einige davon bereits durch Hacks
und Tricks der Webentwickler simuliert wurden. Mit den Server-Sent Events ist es nun möglich, Nachrichten vom Server an den Client zu senden und mit WebSockets können sogar bidirektional Nachrichten verschickt werden (Abbildung 3.1b). Beide erlauben auch Cross-Domain Anfragen, wie sie mit CORS auch für XHRs ermöglicht werden. Mit
der Web Messaging Schnittstelle (postMessage()) ist es nun möglich, Nachrichten auch an andere Browserkontexte zu
versenden.
Abbildung 3.1b stellt die neuen Kommunikationswege dar und wird in den Kapiteln, in denen sie vorgestellt werden,
zur Visualisierung der Technologie verwendet.
Mit HTML5 werden eine ganze Reihe neuer Tags, wie <nav> für Navigationselemente und <progress> für Fortschrittsbalken, eingeführt. Einige Elemente haben auch neue Attribute und Funktionen erhalten. Vieles ist nützlich für
Web-Entwickler, hat aber wenig Einfluss auf die Sicherheit. Einige sicherheitskritische Neuerungen in HTML5 werden
nachfolgend vorgestellt und analysiert.
8
3.1 Web Messaging
Die Entwicklung des Webs hin zu mehr Dynamik und Interaktivität erfordert die Kommunikation zwischen Webseiten
verschiedener Domains.
Bisher konnte diese Kommunikation nur durch Umwege ermöglicht werden. Der Kommunikationspartner wurde in ein
eingebettetes Frame geladen und überwachte die Änderungen am Fragment-Identifier1 , der am Ende einer URL2 durch
ein „#“ (Hash) eingeleitet wird. Beim Aufruf der selben URL mit anderem Fragment-Identifier wird die Seite nicht neu
geladen, sondern zur gleichnamigen Stelle der Seite gesprungen, falls diese definiert wurde. Durch das Reagieren auf
dieses Hashchange-Event wurde eine unidirektionale Kommunikation ermöglicht. Der Sender und Empfänger müssen
allerdings zuvor vereinbaren, wie auf eine Änderung reagiert werden soll.
Da die SOP jedoch weitere Interaktion mit anderen Webseiten verbietet, bedarf es einer neuen Schnittstelle, um den
neuen Anforderungen gerecht zu werden. Diese wird mit HTML5 eingeführt und im Folgenden vorgestellt.
3.1.1 Spezifikation
Web Messaging stellt eine Schnittstelle bereit, um mit Browserkontexten beliebiger Domains bidirektional zu kommunizieren. Die Spezifikation ist unter [59] zu finden.
Für diese Interaktion gibt es die postMessage-Methode, die schon von allen Browsern – wie in Tabelle 3.1 zu sehen – unterstützt wird. Zum Web Messaging gehört auch der MessageChannel, der bisher nur von Chrome und Opera
implementiert wird. Auf ihn wird später ebenfalls eingegangen.
Beide Technologien finden besonders bei MashUps, wie der persönlichen Startseite iGoogle3 von Google, großen Einsatz, da hier eine Vielzahl von Diensten verschiedener Domains zusammengefasst wird, was durch solche Kommunikation
deutlich vereinfacht und dazu sicherer wird.
postMessage
Die postMessage-Methode konsumiert drei Parameter:
message, targetOrigin und transfer. Der Dritte ist optioBrowser
postMessage MessageChannels
nal.
Chrome
ja
ja
Der Parameter message ist die Nachricht, die übermittelt
ja
nein
Firefox
werden soll. Sie kann aus einem primitiven Datentyp, wie
Internet Explorer
ja
nein
String oder Integer, oder einem zusammengesetzten Typ,
Opera
ja
ja
wie ein JSON4 -Objekt oder Array bestehen. Von Prototypen
Safari
ja
nein
abgeleitete Objekte können nicht übermittelt werden, da
keine Schnittstelle existiert, mit der definiert werden kann,
Tabelle 3.1: Unterstützung Web Messaging
wie ein solches Objekt serialisiert werden soll.
Mit TargetOrigin wird die Domain des gewünschten Empfängers angegeben. Der Browser sorgt dafür, dass nur
passende Domains die per postMessage() versendete Nachricht erhalten. Eine Wildcard „*“ ist möglich, um auf diese
Prüfung zu verzichten und die Nachricht an eine potentiell unbekannte Domain ausliefern zu lassen.
1
2
3
4
Bsp.: http://example.com/path/file.html#fragment_identifier
Unified Ressource Locator
http://www.google.com/ig
JavaScript Object Notation http://json.org
9
Der dritte, optionale Parameter transfer ist ein Array von Objekten, die das Interface „Transferable“ implementieren.
Alle dort angegebenen Objekte werden an den Empfänger übertragen und sind beim Sender nach der Übertragung nicht
mehr vorhanden.
Die postMessage-Methode kann auf dem Window-Objekt eines Kontextes aufgerufen werden. Daher muss dem Aufrufer
der Kontext durch eine Referenz bekannt sein. Eine Referenz kann ein IFrame (Zeile 1 in Listing 3.1), der Elternkontext
(parent, Zeile 2) oder ein per JavaScript geöffnetes Fenster (Zeile 3 und 4) sein. Die Kontexte stehen also in einer
direkten Eltern-Kind-Verwandschaft.
1
2
3
4
5
6
7
8
document . getElementsByTagName (" iframe ")[0]. contentWindow . postMessage ("", "*");
parent . postMessage ("", "*");
var w = window .open("index.html", " _blank ");
w. postMessage ("", "*");
// Moeglichkeit 1
// Moeglichkeit 2
// Moeglichkeit 3
window . onmessage = function (event) {
// reagiere auf das Ereignis
}
Listing 3.1: Aufrufe der postMessage()-Methode
Im empfangenden Fenster wird ein Message-Event ausgelöst, auf welches mit dem Event-Listener reagiert werden
kann (Zeile 6-9 in Listing 3.1). Das Ereignis event enthält die folgenden Attribute:
• data – Die übertragene Nachricht. Kann aus einem String, Zahl, Array oder JSON bestehen
• origin – Der Origin der sendenden Domain
• source – Objekt des sendenden Kontextes
• ports – Übermittelte Objekte
Die Integrität der Nachricht data wird durch den Browser sichergestellt. Er garantiert, dass die Nachricht zwischen Aufruf der postMessage()-Methode und Auslesen des Events nicht verändert wurde, indem er die Verteilung der Nachrichten
an die Empfänger kontrolliert, ohne sie zu verändern. Die übrigen Attribute werden im Folgenden vorgestellt.
MessageChannels
Ein MessageChannel enthält zwei MessagePort Objekte port1 und port2, die ebenfalls die postMessage-Methode unterstützen. Diese akzeptiert allerdings nur genau einen Parameter, nämlich die Nachricht (message), wie oben beschrieben.
Der MessageChannel ist ein Tunnel für bidirektionale Kommunikation, dessen Enden, die Ports, verschoben werden
können. Er ermöglicht den Besitzern der Ports direkte Kommunikation und wird von den Web Workern benutzt (siehe
Abschnitt 3.2). Der Einsatz eines solchen Tunnels ist nur dann sinnvoll, wenn ein Ende an einen Partner weitergegeben wird, wie in Listing 3.2 dargestellt. Ein Kontext erstellt einen Channel und versendet einen der beiden Ports per
postMessage() an ein anderes Fenster. Hierfür wird der Port als Element des optionalen Arrays übergeben.
3.1.2 Anwendung
1
2
3
var channel = new MessageChannel ();
otherwindow . postMessage ("", "*", [ channel .port2 ])
channel .port1. postMessage ("");
Listing 3.2: MessageChannel und Versenden eines Ports
1
2
3
4
5
window . onmessage = function (e) {
event . ports [0]. postMessage ("");
// ODER
thirdwindow . postMessage ("", "*", e. ports );
}
Listing 3.3: Empfangen eines Ports
Allein durch die Weitergabe eines Ports des MessageChannels ensteht kein Vorteil aus dieser Möglichkeit, da die beiden
Kontexte vorher bereits in der Lage waren, miteinander zu kommunizieren. Einen Nutzen hat die Übertragung von Ports
erst im Szenario, das in Abbildung 3.2 dargestellt wird. Ein Kontext erstellt zwei eingebettete Frames, mit denen er, wie
in Listing 3.1 Zeile 1 gezeigt, kommunizieren kann. Möchten die beiden Frames miteinander kommunizieren, ist das nur
durch einen Proxycode möglich, der die Nachrichten (1a und 1b) an den jeweils anderen Kontext weiterleitet. In jedem
Fall ist der Elternkontext in die Kommunikation involviert, ohne dass er daran teilnimmt.
Mit einem MessageChannel, der von Frame 1 erstellt wird, können die beiden Frames ohne Zwischenstellen kommunizieren. Dafür muss einmalig der Port mit Hilfe des Parent an Frame 2 geschickt werden. Das könnte direkt über das
10
Window-Objekt geschehen, auf das ein Frame der gleichen Domain per parent-Attribut Zugriff hat (Listing 3.1, Zeile 2)
oder über das source-Attribut des Events, wie in Abschnitt 3.1.3. Für diese Methoden braucht der Frame neben dem Zugriff (SOP) jedoch Wissen über die Struktur, um durch die Hierarchie an den eingeschachtelten Kontext heranzukommen.
Deshalb ist es einfacher, Code im Elternkontext bereitzustellen, der den Port (2a) an Frame 2 weiterleitet. Das geschieht
wie in Listing 3.3 Zeile 4 beschrieben.
Anschließend können Frame 1 und Frame 2 direkt Nachrichten austauschen (2b). Das Szenario lässt sich so erweitern,
dass sogar der Elternkontext geschlossen werden kann und beide Frames weiter miteinander kommunizieren können,
solange sie existieren. Hier darf Parent die Seiten nicht in ein IFrame laden, sonder muss für jede Seite ein neues Fenster
oder einen neuen Tab öffnen, damit sie beim Schließen des Parents nicht automatisch ebenfalls geschlossen werden.
Anschließend muss wieder der Port ausgetauscht werden. Diese Aktion kann auch vom Parentframe ausgehen, der
ein MessageChannel-Objekt erstellt und beide Ports an seine Kindelemente weitergibt. Nun können die Subkontexte
unabhängig von der Existenz des Elternkontext kommunizieren, was vorher nicht möglich war.
Abbildung 3.2: Weiterleiten des Port Objektes
Protokolle
Mit Google Friend Connect5 und Facebook Connect6 sind bereits zwei Implementierungen im Einsatz, die postMessage()
verwenden [18]. Hier lädt eine Webseite, die Zugriff auf Informationen von Facebook oder Google haben möchte, die
entsprechende Seite in ein IFrame und kommuniziert mit dieser per postMessage(). Beispielsweise, um den Benutzer
auf der Webseite mit dem Google- oder Facebook-Konto anzumelden. Es treten jedoch einige Probleme auf, die im
Abschnitt Sicherheitsaspekte besprochen werden.
Transferable Objekte
Wie bereits erwähnt, müssen die Objekte, die im dritten Parameter, dem Array ports, übergeben werden, die Schnittstelle „Transferable“ implementieren. In der Tat ist der MessagePort das einzige Objekt der Spezifikation, das diese
Schnittstelle verwendet [56]. Das bedeutet, dass man mittels postMessage() nur Ports verschieben kann und das vorgestellte Szenario und die SharedWorker (siehe Kapitel 3.2) die einzige Anwendungsmöglichkeit des dritten Parameters ist.
Weiterhin legt die Festlegung des Attributnamens auf „ports“ im Event die Intention nahe, dass Ports auch die einzigen
„Transferable“-Objekte bleiben.
5
6
http://www.google.com/friendconnect/home/overview?hl=de
https://blog.facebook.com/blog.php?post=24577977130
11
3.1.3 Sicherheitsaspekte
Die SOP verbietet den Aufruf fremder Domains durch XHR. Daher haben Facebook und Google eigene Protokolle vorgestellt, die es einer beliebigen Domain erlauben, mit Facebook und Google zu kommunizieren. Das Ziel dieser Protokolle
ist es, sich auf der Domain (Implementor) mit seinem jeweiligen Benutzerkonto zu authentifizieren. Das Prinzip ist in
beiden gleich: Facebook oder Google wird in ein Proxy-IFrame geladen, das die per postMessage() gesendete Nachricht
dann weiterleitet und die Antwort des Servers wiederum per postMessage() zurückgibt (siehe Abbildung 3.3) [18].
Am Beispiel dieser Protokolle werden nun einige Schwierigkeiten von Web Messaging illustriert.
Origin
Mit den beiden Protokollen werden auch sensitive Daten, wie Profilinformationen, übertragen, weshalb die Nachrichten vertraulich und integer bleiben sollten.
Mit dem targetOrigin-Argument der postMessage-Methode kann
der Sender auswählen, welche Domain die Nachricht empfangen darf.
Der Browser stellt die Vertraulichkeit sicher, indem er die Nachricht
nur an den spezifizierten Empfänger ausliefert. Es wird empfohlen
hier einen echten Origin als Attribut anzugeben [59] und nicht, wie
in Listing 3.1, die Wildcard zu benutzen.
Facebook Connect nutzt die Wildcard und ermöglicht einem Angreifer, sich zwischen Implementor und Proxy-Frame zu schalten,
um einen Man-In-The-Middle-Angriff auszuführen. Das Problem, das
Facebook versucht mit der Wildcard zu lösen, ist die Strenge des
targetOrigin, das nur eine Domain zulässt, obwohl in diesem, von
Abbildung 3.3: Facebook Connect Schema [18]
Steve Hanna beschriebenen Anwendungsfall, auch Subdomains nötig
wären [18]. Es besteht also nur die Möglichkeit, Uni- oder Broadcast
Nachrichten zu senden, benötigt würde allerdings Multicast. Hanna schlägt deshalb vor, auch Wildcards der Form „*.facebook.com“ zuzulassen [18], damit die Vertraulichkeit nicht dem strikten targetOrigin zum Opfer falle. Der Vorschlag
hat es bis jetzt jedoch nicht in den Standard geschafft. Die beiden Protokolle sind bereits in sich inkonsistent bei der
Verwendung des targetOrigin, der manchmal auf eine Domain und manchmal als Wildcard gesetzt wird [18].
Auf der Empfängerseite muss ebenfalls festgelegt werden, von welchen Domains Daten empfangen werden dürfen, um
Authentizität zu gewährleisten. Diese kann nur mit einer Konstruktion wie in Listing 3.4 erreicht werden, die die Herkunft
der Nachricht überprüft, die vom Browser in das Event eingetragen wird. Hier müssen Subdomains durch Disjunktion
behandelt werden, da immer die volle Domain mit Protokoll als Origin übergeben wird. Aufgrund der Tatsache, dass
diese Abfrage schon in der Spezifikation empfohlen wird, stellt sich die Frage, warum hier nicht ein Primitiv angeboten
wird, das diese Aufgabe übernimmt [18]. Hanna schlägt hier eine CSP7 -ähnliche Konstruktion vor, das durch Regeln
einem Kontext vorgibt, von wem Nachrichten empfangen werden dürfen. Hier wäre die Wildcard auch für Subdomains
möglich. In diesem Fall gestaltet es sich allerdings einfacher, zusätzliche Bedingungen in die Verzweigung für weitere
Domains und Subdomains einzufügen.
Neben dem Sicherstellen der Authentizität verhindert eine Identifizierung des Senders Denial-of-Service Angriffe, die
entstehen könnten, wenn der Empfänger komplexe Berechnungen oder hohen Datenverkehr durchführt [59] und daher
leicht durch viele Anfragen überlastet werden kann. Je nach Vertrauen in die sendende Domain kann auch eine Beschränkung der Eingangsfrequenz pro Domain sinnvoll sein [59]. Diese würde im Event-Listener oder sogar im Browser
implementiert werden und müsste beachten, dass, je nach Anwendungsfall, keine wichtigen Nachrichten unterdrückt
werden.
1
2
3
4
5
6
function listener ( event) {
if (event. origin == "http :// www. example .com") {
// nur Nachrichten von example .com werden verarbeitet
}
}
window . addEventListener (" message ", listener );
Listing 3.4: Event-Listener mit Sender-Kontrolle
7
12
Content Security Policy http://www.w3.org/TR/CSP/
Sender Window
Während die Integrität und Vertraulichkeit von einem korrekt implementierten Browser und die Authentizität durch
ein Codestück im Empfänger sichergestellt werden, hat der Empfänger über das source-Attribut des Ereignisses Zugriff
auf den kompletten sendenden Kontext. Hier kommt die schon lange verwendete SOP für JavaScript einschränkend zum
Einsatz. Sie verbietet es einem Frame auf sein parent-Objekt zuzugreifen, wenn es nicht vom gleichen Origin stammt.
Genauso ist auch der Zugriff auf das source-Attribut für den Empfänger verboten, der zwar das Objekt erhält, aber durch
die SOP keine Erlaubnis zum Lesen oder Schreiben auf diesem Objekt bekommt, wenn es sich um einen anderen Origin
handelt.
Um eine Antwort zu ermöglichen, wird jedoch eine Ausnahme gemacht. Der Empfänger kann den Aufruf
e.source.postMessage(”Nachricht”, e.origin) auf dem source-Attribut ausführen, ohne von der SOP blockiert zu
werden, und auf diese Art leicht auf eine eingehende Nachricht antworten.
Mit Web Messaging und den MessageChannels stellt HTML5 neue Interaktionsmöglichkeiten zwischen Browserkontexten vor. Die Schnittstelle kann jedoch nicht nur von Web Entwicklern beim Erstellen von Webanwendungen verwendet
werden, um zwischen Webseiten zu kommunizieren. Sie wird auch bei bei der Definition der Web Worker wiederverwendet.
Beachtet der Entwickler die korrekte Adressierung mittels targetOrigin und prüft empfangene Nachrichten auf den
Absender, werden die Schutzziele gewährleistet und die Web Messaging Schnittstelle in sicherer Art verwendet.
13
3.2 Web Worker
Abbildung 3.4: Web Worker
Das Konzept der Web Worker ermöglicht dem Programmierer, Berechnungen in einem JavaScript vom Kontext der
Darstellung einer Webseite zu entkoppeln. Komplexe Berechnungen können so ausgelagert werden und blockieren nicht
mehr Skripte, die für die Oberfläche zuständig sind. Mit SharedWorkers ist es zusätzlich möglich, einen Worker in mehreren Kontexten gleichzeitig zu verwenden.
3.2.1 Spezifikation
Das W3C sieht für die Worker eine extra Spezifikation außerhalb von HTML5 vor [61]. Die WHATWG nimmt sie jedoch
in ihre Spezifikation von HTML auf [70]. Die Worker sind unabhängig von der Benutzeroberfläche und werden daher
nicht durch Mausklicks oder andere Eingaben unterbrochen. Man kann sich diese Eigenschaft so ähnlich wie Threading
in Programmiersprachen, wie etwa Java, vorstellen. Die Worker eignen sich für komplexere Berechnungen oder asynchrone Kommunikation mit dem Server, die keine Eingabe vom Benutzer erfordert. Es gibt zwei Typen von Workern, die
dezidierten Worker (kurz Worker) und die SharedWorker. Letztere erlauben zusätzlich den Zugriff von mehr als einem
Browserkontext, also verschiedenen Browserfenstern (des selben Browsers) oder Tabs.
Erstellt wird ein Worker über die Konstruktoren new Worker("worker.js") und new SharedWorker("worker.js")
für SharedWorker. Der Worker bekommt den gleichen Origin wie der erstellende Kontext. Anschließend kann die Benutzeroberfläche über die Web Messaging Schnittstellen postMessage() und port.postMessage() String- oder ObjektNachrichten mit dem Worker austauschen, wie in Abschnitt Web Messaging beschrieben (siehe auch Abbildung 3.4). Bei
einem SharedWorker wird implizit ein MessageChannel erstellt und einer der beiden Ports an den Worker übertragen.
Der andere verbleibt beim Ersteller und kann von diesem zur Kommunikation mit dem Worker genutzt werden.
Um Nachrichten entgegen zu nehmen, muss der Worker (hier das JavaScript worker.js) den Event-Listener
onmessage implementieren, dieser erhält die per postMessage() gesendete Nachricht. Die Spezifikation sieht dieses
Kommunikationsschema auch für den umgekehrten Weg von Worker nach Benutzeroberfläche vor. Im folgenden Listing
findet sich ein Beispiel für Worker. Für SharedWorker ist ein Beispiel in den Listings 3.8 und 3.9 zu finden.
1
2
3
4
5
6
7
var worker = new Worker (" worker .js");
worker . onmessage = function (event) {
// Nachricht in event.data
}
1
2
3
4
5
onmessage = function ( event ) {
// Sende empfangene
// Nachricht zurueck
postMessage ( event .data);
}
// Sende Nachricht an Worker
worker . postMessage (" Nachricht ");
Listing 3.5: Worker im Benutzerkontext
Listing 3.6: Kontext des Workers (worker.js)
Ein SharedWorker besitzt zusätzlich den Event-Listener onconnect, der aufgerufen wird, wenn der Worker über einen
Konstruktor erstellt wird. Das gilt auch, wenn ein zweiter Browserkontext auf den Worker zugreift (siehe Beispiel im
Absatz Anwendung).
Ein Worker oder SharedWorker kann sich mit der Funktion close() selbst beenden. Der Kontext, der den Worker
gestartet hat, bleibt davon unberührt. Ein dezidierter Worker kann von seinem Besitzer über die Funktion terminate
beendet werden.
Die Laufzeit eines Workers endet spätestens, wenn der letzte Browserkontext, der eine Verbindung zu ihm unterhält,
geschlossen wird.
14
3.2.2 Anwendung
Die Unterstützung von Workern und SharedWorkern der jeweiligen Browser ist in Tabelle 3.2 angegeben. Bei Opera existiert
Browser
Worker SharedWorkers
ein Problem mit SharedWorkern, welches im Abschnitt SicherChrome
ja
ja
heitsaspekte besprochen wird. Deshalb wurde die ImplemenFirefox
ja
nein
tierung in Klammern vermerkt.
Internet Explorer
nein
nein
In Abbildung 3.5 ist beispielhaft eine Laufzeit eines SharedOpera
ja
(ja)
Workers dargestellt. Die eigentliche Aufgabe des Workers, die
ja
ja
Safari
Berechnung unabhängig von der Benutzerschnittstelle, wird
Tabelle 3.2: Unterstützung Workers und WebWorkers
nicht dargestellt. Hier kann beliebiger JavaScript-Code eingesetzt werden, der nicht HTML5 spezifisch ist. Die Abbildung
zeigt vereinfacht die Kommunikation zwischen Kontexten und dem SharedWorker.
Der Worker wird in der Abbildung von Kontext 1 mit dem Konstruktor new SharedWorker("worker.js") (1) erstellt.
Hier wird auch die Instanz erzeugt. Im Worker kann mit der onconnect-Methode (2) darauf reagiert werden; sie ist
ähnlich dem Konstruktor in einer objektorientierten Programmiersprache. Versucht ein anderer Kontext (hier: Kontext
2) die gleiche Datei als Worker zu instanziieren (3), wird auf den bereits Existierenden zurückgegriffen, der wieder
onconnect (3.1) ausführt, um die Verbindung zu initialisieren. Es wird keine neue Instanz erzeugt. Das Beispiel beschränkt sich auf drei Kontexte; theoretisch sind jedoch beliebig viele innerhalb des Browsers möglich. Zu sehen ist, dass
beliebige Kommunikation (4,5,6) zwischen Worker und Kontexten möglich ist.
Das Aufrufen der postMessage-Methode auf der Senderseite führt zur Ausführung der onmessage-Methode auf der
Empfängerseite. Ein direktes Kommunizieren zwischen den drei Kontexten ist nur mit dem Worker als Vermittler möglich
– für direkte Verbindungen sieht HTML eigentlich Web Messaging vor.
Abbildung 3.5: SharedWorker mit drei Browserkontexten (vereinfacht)
Man erkennt, dass nach dem Beenden des Kontextes, der den Worker gestartet hat, der Zugriff von neuen Kontexten (7)
auf den Worker und Kommunikation (8) weiterhin möglich ist.
15
In dem Beispiel reagiert der Worker auf die Nachricht „close“ (7) mit dem Aufruf der close-Methode (7.1), wie in
Listing 3.9 implementiert – der Worker wird beendet. Mit dieser Implementierung ist das Schließen des Workers von
beliebigen Kontexten ausgehend möglich. Ein Beenden ohne den Einfluß des SharedWorkers ist nicht möglich. In dem
Beispiel laufen zwei Kontexte weiter, wenn der Worker beendet ist. Wenn der Worker sich auf diese Art nicht selbst
beendet, wird er erst geschlossen, wenn der letzte Kontext, der Zugriff auf den Worker hatte, beendet wird. Das bedeutet
insbesondere, dass der erstellende Kontext (Kontext 1) beendet werden kann, ohne Einfluss auf den Worker zu nehmen.
Das Laden und Ausführen von JavaScript ist beim Betrachten von Webseiten der kritischste Teil und am anfälligsten für
Attacken, wie XSS8 . Das zeigt die OWASP Top 10 Liste der Sicherheitsrisiken in Webanwendungen [72]. Daher ist bei der
Implementierung der Web Worker darauf zu achten, dass dadurch keines der bekannten Angriffsszenarien ermöglicht
wird.
Angriff von fremder Domain
Abbildung 3.6: attacker.com instanziiert Worker
Ein mögliches Angriffsszenario ist der Versuch von einer fremden Domain auf einen SharedWorker von example.com zuzugreifen. Ein Angreifer präpariert eine Webseite (attacker.com) so, dass sie versucht den Worker auf
example.com/worker zu starten, wie in Listing 3.7 am Ende
des Abschnittes.
Gelingt dieser Aufruf, könnte der Angreifer über die
postMessage-Schnittstelle Nachrichten vom Worker empfangen und an ihn senden. Die Implementierung ist dem
Angreifer bekannt, da es sich um clientseitiges JavaScript
handelt und er sie sich einfach herunterladen kann. Liefe in einem zweiten Kontext bereits der von example.com
instanziierte Worker, könnte der Angreifer Einfluss auf das
Verhalten des Workers und der Webseite von example.com
nehmen und Informationen stehlen.
Die Spezifikation verhindert diesen Angriff durch die Einschränkung, dass die URL des Worker-Skriptes und die URL
des startenden Kontextes den selben Origin aufweisen müssen. Das Starten eines Workers einer fremden Domain wird
daher unterbunden. Dies entspricht der Implementierung der SOP.
1
2
3
4
5
try {
var worker = new SharedWorker ("http :// example .com/ worker .js");
} catch (e) {
// worker could not be started
}
Listing 3.7: SharedWorker von fremder Domain: JavaScript auf attacker.com
Ausnutzen von XSS-Lücken
Besteht auf einer Webseite, die einen Worker verwendet, eine XSS-Lücke, so ist ein Angreifer in der Lage die Lücke
auszunutzen und beliebig - insbesondere mit einem SharedWorker - zu kommunizieren. Ein Worker bietet also keinen
zusätzlichen Schutz vor XSS-Attacken gegenüber herkömmlichen Instanzen von JavaScript.
Opera
Beim Testen der Spezifikation fällt auf, dass sich die aktuelle Version von Opera (11.64 - 12.02) nicht exakt an die
Spezifikation hält. Das in Listing 3.8 dargestellte JavaScript läuft im Benutzerkontext, also in einem Tab, der eine Webseite
darstellt. Das Skript erwartet die durch die Kommentare angedeuteten Antworten von einem Worker, wie in Listing 3.9.
Der Worker antwortet auf jede ankommende Nachricht mit dem String „pong“. Bekommt er als Nachricht jedoch den
String „close“, führt er vor der Antwort die Funktion close() aus. Nach dem Verlassen der onmessage-Methode wird der
Worker gelöscht. Auf ein „close“ antwortet der Worker also noch mit einem „pong“, ist danach aber nicht mehr erreichbar.
In Opera Version 11.64 ist diese Methode nicht – oder nicht korrekt – implementiert, da jede weitere Nachricht nach
einem „close“ wider Erwarten ein „pong“ als Antwort erhält.
8
16
Cross-Site Scripting
1
2
3
4
5
6
7
8
var worker = new SharedWorker (" worker .js"). start ();
worker .port. postMessage ("");
// Antwort : pong
worker .port. postMessage ("close");
// Antwort : pong
worker .port. postMessage ("");
// keine Antwort erwartet
// Opera : pong
worker .port. onmessage = function (event) {
}
Listing 3.8: SharedWorker: Benutzerkontext
1
2
3
4
5
6
7
8
onconnect = function (e) {
var port = e. ports [0];
port. onmessage = function (e) {
if (e.data == " close ")
close ();
port. postMessage ("pong");
}
}
Listing 3.9: worker.js
Direkte Folge dieses Problems ist die Belegung von Arbeitsspeicher und Prozessor, da die Ressourcen des Workers
nicht, wie vom Entwickler erwartet, nach dem Aufruf von close() freigegeben werden. Im Worker gespeicherte sensitive
Daten sind damit ebenfalls noch verfügbar und können weiterhin ausgelesen werden.
Botnetz
Die Web Worker sind der Gefahr ausgesetzt, in einem Botnetz missbraucht zu werden. Eine Webseite mit ausreichend
großer Anzahl Nutzer könnte bei jedem Besuch einen Worker auf dem Client starten, der dann in einem verteilten System
Berechnungen ausführt. Beispielsweise die kryptographisch aufwendige Berechnung von Bitcoins9 .
Lavakumar Kuppan von Andlabs hat ein System vorgestellt, das mittels Web Workern versucht zu einer gegebenen Hashfunktion die notwendige Eingabe zu berechnen, um einen gegebenen Hashwert zu bekommen [5]. Also die
Hashfunktion zu invertieren, was bei Hashfunktionen per Definition nur mit enormem Aufwand möglich sein darf. Auf
hinreichend vielen Clients gleichzeitig ausgeführt kann so ein Hash gebrochen werden.
Wenn ein Worker Teil eines Botnetzes ist, kann das nur durch einen Experten erkannt werden. Ein normaler Internetbenutzer kann noch nicht einmal feststellen, ob überhaupt ein Worker auf einer Webseite eingesetzt wird. Selbst wenn
dies möglich wäre, ist es schwierig zu ersehen, welche Funktion ein Worker erfüllt. Ein Indiz für den Missbrauch ist eine
hohe CPU-Last, die vom Worker verursacht wird. Allerdings ist die Ursache für eine hohe Last für den Laien ebenfalls
kaum auszumachen.
Die Web Worker erweitern JavaScript um ein Konzept ähnlich zu Threads, sodass sich Skripte auf dem DOM nicht
durch langwierige Berechnungen gegenseitig unterbrechen. Mehrere Kontexte einer Domain können gemeinsam auf
eine Instanz eines SharedWorker zugreifen, wodurch redundante Berechnungen vermieden werden. Die Worker sind
durch die SOP gut geschützt, können aber auch für andere Zwecke missbraucht werden, ohne das der Benutzer es
bemerkt.
9
http://bitcoin.org/
17
3.3 Das keygen Element
Das <keygen>-Element war ein browserspezifisches Element des 1998 eingestellten Netscape Navigators [34, 65]. Es
wurde dazu verwendet, asymmetrische Schlüsselpaare benutzerseitig zu generieren und den öffentlichen Schlüssel an
den Server zu schicken. HTML5 nimmt das Element in den Standard auf [51].
3.3.1 Spezifikation
Der <keygen>-Tag wird in Formularen verwendet. Beim Absenden eines Formulares, das ein solches Element enthält, wird vom
Browser ein asymmetrisches Schlüsselpaar erzeugt. Der öffentliche Schlüssel wird mit der im Formular spezifizierten Methode
(GET/POST) an das Formularziel gesendet. Dafür wird der öffentliche Schlüssel mit dem privaten Schlüssel signiert. Anschließend
werden öffentlicher Schlüssel, Signaturalgorithmus und Signatur
in Form der ASN.1 Struktur [12] SPKAC10 in Listing 3.10 an den
Server gesendet.
Tabelle 3.3: Algorithmen für das keygen-Element
Das Attribut challenge kann im <keygen>-Element spezifiziert
werden, wie in Listing 3.11 dargestellt. Wird es nicht angegeben, wird der leere String verwendet. Es wird mit dem
öffentlichen Schlüssel signiert und an den Server gesendet.
Browser
Chrome
Firefox
Internet Explorer
Opera
Safari
1
2
3
4
5
6
7
8
9
10
Algorithmen
RSA
RSA, DSA, EC
nicht unterstützt
RSA
nicht unterstützt
PublicKeyAndChallenge ::= SEQUENCE {
spki SubjectPublicKeyInfo ,
challenge IA5STRING
}
SignedPublicKeyAndChallenge ::= SEQUENCE {
publicKeyAndChallenge PublicKeyAndChallenge ,
signatureAlgorithm AlgorithmIdentifier ,
signature BIT STRING
}
Listing 3.10: ASN.1 Definition des übertragenen öffentlichen Schlüssels
Die Spezifikation sieht vor, den privaten Schlüssel im lokalen Schlüsselspeicher abzulegen. Wie auf Serverseite mit
dem öffentlichen Schlüssel verfahren werden soll, ist nicht Teil der Spezifikation, da sich diese nur auf die Clientseite
bezieht.
Der Algorithmus, der zum Generieren des Schlüsselpaares verwendet werden soll, ist nicht spezifiziert, obwohl er sich
über das Attribut keytype festlegen lässt. Eine Übersicht über die unterstützen Algorithmen wird in Tabelle 3.3 gegeben,
wobei empfohlen wird, mindestens RSA11 anzubieten.
Ein Beispiel ist in Listing 3.11 dargestellt. Die Attribute keytype und challenge ist optional. Ist es leer, oder wird ganz
weggelassen, soll RSA verwendet werden, falls der Browser diesen Algorithmus unterstützt.
1
2
3
4
<form action =" generate_key .php">
<keygen name="key" keytype ="rsa" challenge =" challenge ">
<input type=" submit " value ="Sende Schluessel ">
</form >
Listing 3.11: Verwendung des keygen-Elements
3.3.2 Anwendung
Das <keygen>-Element wird von allen gängigen Browsern außer Internet Explorer und Safari unterstützt (siehe Tabelle 3.3). Die Darstellung des Elementes ist nicht spezifiziert, wodurch sich die aktuellen Implementierungen unterscheiden.
Die Browser lassen den Benutzer die Länge des generierten Schlüsselpaares einstellen. Im Fall von RSA lässt Opera hier
am meisten Auswahlmöglichkeit von insgesamt 13 Schlüssellängen zwischen 1024 und 4096 bit. Firefox und Chrome
bieten jeweils 1024 und 2048 bit an.
10
11
18
SignedPublicKeyAndChallenge
Kryptographisches Verfahren nach Rivest, Shamir und Adleman [37]
Da die Reaktion des Servers auf einen empfangenen öffentlichen Schlüssel nicht definiert ist, kann man hier je nach
Implementierung verschiedenes Verhalten der Browser beobachten. Antwortet der Server mit einer einfachen HTMLSeite, ist für den Benutzer nicht erkennbar, was mit dem privaten Schlüssel passiert. Bei Firefox und Chrome wird kein
Schlüssel in dem entsprechenden Menü angezeigt. Opera hingegen gibt, wie in Abbildung 3.7a gezeigt, einen erstellten privaten Schlüssel an. Über diesen lassen sich allerdings keine weiteren Informationen abrufen. Das Dialogfenster
bleibt leer. Es existiert auch keine API, mit dem man auf den gespeicherten Schlüssel Zugriff hätte. Angenommen diese
existierte, dann hätte man die Möglichkeit, clientseitig in JavaScript Verschlüsselungs- und Signaturverfahren mit dem
abgelegten Schlüssel durchzuführen. Im September 2012 wurde vom W3C die „Web Cryptography API“ vorgestellt, die
genau diese Schnittstellen beschreibt [58]. Zur Zeit warten die Autoren auf Feedback von Web Entwicklern, um den
Entwurf zu einem Standard weiterzuentwickeln. Implementierungen existieren auf Grund des frühen Stadiums natürlich
noch nicht.
Ansonsten ist die Anwendungsmöglichkeit auf die zertifikatsbasierte Authentifizierung beschränkt. Dies wird auch in
der Spezifikation vorgeschlagen, ist jedoch nicht verbindlich. Wird ein korrekt erstelltes Zertifikat (siehe Beispielcode
in [43]) zurückgeliefert, wird der Benutzer darüber informiert und das Zertifikat im Browser abgelegt. Das Zertifikat
wird anschließend auch angezeigt; hierbei verhalten sich die Browser gleich. In Abbildung 3.7b ist Opera beispielhaft
aufgeführt.
Startcom12 benutzt dieses Verfahren bereits, um seinen Benutzern eine Anmeldung zu ermöglichen. Hierbei ist zu
beachten, dass das Zertifikat im Browser abgespeichert wird. Jede Person, die Zugriff auf diesen Browser - genauer
dessen Zertifikatsverwaltung - hat, kann das Zertifikat zur Authentifizierung benutzen.
(a) Kein Zertifikat, aber privater Schlüssel
(b) Vom Server gesendetes Zertifikat
Abbildung 3.7: Opera Zertifikatsverwaltung
Übertragung und Challenge
Alice muss beim Generieren des Schlüssels nicht darauf achten, dass das SPKAC-Format durch eine gesicherte Verbindung, wie HTTPS, übertragen wird. Eine Verletzung der Schutzziele bei der Übertragung hat keine Auswirkung auf die
Benutzung des Zertifikates, da ein sinnvoller Angriff auf den privaten Schlüssel zielt, der auf dem Computer verbleibt.
Das Zertifikat kann Mallory in die Hände bekommen, da es nur bestätigt, dass Alice den passenden privaten Schlüssel zu
dem öffentlichen in dem Zertifikat besitzt. Mallory kann sich nicht damit authentifizieren, da jedes passende Protokoll
die Kenntnis des privaten Schlüssels überprüft.
Das challenge-Attribut verändert die Signatur der PublicKeyAndChallenge-Struktur, sodass der gleiche öffentliche
Schlüssel mit gleichen Informationen eine andere Signatur erzeugt, wenn sich die Challenge unterscheidet. Diese zusätzliche Entropie ist jedoch nicht notwendig, da im Zertifikat der öffentliche Schlüssel ohnehin erkennbar ist und in
einer PKI13 sowieso veröffentlicht würde. Eine mögliche Rechtfertigung für das challenge-Attribut ist die Gefahr von
Replay-Angriffen. Diese ist jedoch nicht gegeben, weil Mallory nur aus dem privaten Schlüssel Nutzen ziehen kann, der
nicht übertragen wird. Tatsächlich wurde das Attribut nur in den Standard aufgenommen, um weiterhin Seiten zu unterstützen, die das <keygen>-Element aus Netscape Zeiten benutzen (siehe Anhang A), da sich die Verwendung etabliert
hatte.
Der <keygen>-Tag erstellt ein asymmetrisches Schlüsselpaar, das statt einer Benutzername-Passwort-Authentifikation
verwendet werden kann. Da der private Schlüssel im Browser verbleibt, ist er gegen jeden Angriff über das Internet
geschützt.
12
13
http://www.startssl.com/
Public Key Infrastructure [12]
19
3.4 Web Storage
Bisher war das Speichern von Daten im Browser nur beschränkt durch Cookies möglich. Nur Plugins, wie Flash und Silverlight, ermöglichen das Ablegen von größeren Mengen an Information. Mit dem Web Storage [60] bietet HTML5
Webentwicklern die Möglichkeit 5 MB Daten lokal auf den Clientrechnern abzulegen. Der Zugriff erfolgt über eine
Schlüssel/Wert-Schnittstelle.
3.4.1 Spezifikation
Das W3C hält für den Web Storage oder lokalen Speicher eine von HTML5 entkoppelte Spezifikation bereit [64], während
die WHATWG sie als Teil von HTML veröffentlicht [69]. Der Web Storage besitzt Methoden zum Speichern (setItem(key,
value)), Laden (getItem(key)) und Löschen (removeItem(key)) von Einträgen (key). Der komplette Speicher kann mit
clear() gelöscht werden. Darüber hinaus kann mit der Methode key(n) der Schlüssel des n-ten Eintrags abgefragt werden, wobei die Spezifikation der Implementierung freistellt, die Indizies beim Hinzufügen oder Entfernen von Elementen
zu verändern.
Bei jeder Veränderung des Speichers wird ein Storage-Event ausgelöst, dass jedes Dokument, das gerade Zugriff auf
den Web Storage hat, über die Änderung informiert. Das Event enthält den Schlüssel (key), den alten und neuen Wert
(oldValue, newValue), die Adresse des auslösenden Dokumentes (url) und das Web Storage-Objekt (storageArea), das
verändert wurde, als Attribut.
Jede Domain (jedes Origin) besitzt einen eigenen Web Storage. Sie hat nur Zugriff auf diesen und auf keinen anderen.
LocalStorage SessionStorage
Browser
Der Web Storage unterscheidet zwei Typen von Speichern:
Chrome
ja
ja
den LocalStorage und den SessionStorage, die sich in der Perja
ja
Firefox
sistenz der Daten unterscheiden. Die im SessionStorage abInternet Explorer
ja
ja
gelegten Daten müssen laut Spezifikation beim Öffnen eines
Opera
ja
ja
Kontextes nicht mehr vorhanden sein, was in der Praxis die
Safari
ja
ja
Löschung des SessionStorage beim Schließen des zugehörigen Kontextes zur Folge hat. Dagegen sollte ein Browser DaTabelle 3.4: Unterstützung Web Storage
ten aus dem LocalStorage nur aus Sicherheitsgründen oder
wenn der Benutzer es fordert löschen. Der SessionStorage wird also nur so lange im Speicher gehalten, wie der zugehörige Browserkontext existiert. Außerdem gibt es nur einen LocalStorage pro Origin, dieser kann also gleichzeitig von
mehreren verschiedenen Kontexten verwendet werden, während für jeden nicht geschachtelten Kontext eines Origin ein
unabhängiger SessionStorage existiert. Bei n geöffneten Tabs einer Domain werden also auch n SessionStorages angelegt.
Die Spezifikation schlägt vor, den Speicherplatz pro Web Storage auf 5 MB zu limitieren.
Internet Explorer
Microsofts Internet Explorer adaptiert die Spezifikation und erweitert sie zusätzlich um zwei Elemente [27]. Das
remainingSpace-Attribut und das storagecommit-Event.
Mit localStorage.remainingSpace oder sessionStorage.remainingSpace lässt sich die verbleibende Speicherkapazität des entsprechenden Web Storage in Bytes abfragen. Jedes Zeichen im Schlüssel und im Wert verbraucht hierbei
ein Byte. Das Attribut wäre auch im Standard interessant, da hier keine Möglichkeit vorgesehen ist, um zu berechnen,
wie viel Speicher noch verfügbar ist. Versucht man einen Wert zu schreiben, für den im lokalen Speicher nicht mehr
genügend Platz ist, wird einfach eine Ausnahme geworfen und das Schreiben verweigert. Man kann also nicht vorher
feststellen, ob das Schreiben noch möglich wäre, wie es mit dem remainingSpace-Attribut machbar ist.
Das storagecommit-Event wird ausgelöst, sobald ein veränderter oder neu erstellter Wert im LocalStorage auf die
Festplatte geschrieben wird. Die Daten im SessionStorage werden nicht auf die Festplatte geschrieben, weshalb das
Ereignis hier nicht anwendbar ist. Die Spezifikation schreibt nicht vor, dass das sofort beim Setzen des Wertes mit
setItem(key, value) geschehen muss, weshalb der Wert für einige Zeit ausschließlich im Arbeitsspeicher vorhanden
sein kann.
Wie jeder moderne Browser stellt der Internet Explorer einen privaten Modus bereit, bei dem keine Spuren vom Surfen
im Internet auf dem Computer hinterlassen werden sollen. Das betrifft sowohl das Speichern von Cookies, als auch den
Verlauf der besuchten Webseiten. Durch Ausnutzen des storagecommit-Ereignisses kann man im Internet Explorer als
Webentwickler feststellen, ob sich der Browser gerade im privaten Modus befindet.
20
1
2
3
4
5
var private = true;
window . localStorage . onstoragecommit = function ( event ) {
private = false ;
}
window . localStorage . setItem ("test", "test");
Listing 3.12: Feststellen des privaten Modus mit LocalStorage
Der Code Listing 3.12 setzt zunächst eine Prüfvariable auf „wahr“; sie gibt an, ob sich der Browser im privaten Modus
befindet. Der storagecommit-Handler wird so implementiert, dass er die Prüfvariable auf „falsch“ setzt, sobald er aufgerufen wird; denn wenn Daten auf die Festplatte geschrieben werden, befindet man sich nicht im privaten Modus. Das
Schreiben auf die Festplatte hinterlässt schließlich eine Spur, was der private Modus verhindern würde. Nach dem Setzen
des Handlers wird ein Wert geschrieben, der im normalen Modus das Ereignis auslöst. Wird das Event nicht ausgelöst,
bleibt die Variable auf „wahr“ und gibt somit an, dass man sich im privaten Modus befindet.
Um die zeitliche Verzögerung zwischen dem Setzen des Wertes und dem Feuern des Ereignisses zu bestimmen, wurde
das Maximum und das arithmetische Mittel aus 1000 Schreibvorgängen betrachtet. Es wurden verschiedene Windows
Versionen seit Windows XP auf unterschiedlichen Maschinen getestet.
Im Schnitt wurden 20 ms zum Schreiben auf die Festplatte benötigt. Das Maximum betrug 72 ms. Es ist wichtig, diese
Tatsache zu betrachten, da die beschriebene Vorgehensweise erst nach dieser Verzögerung korrekte Werte liefern kann.
Global Storage
Der GlobalStorage ist ein Firefox spezifisches Objekt, das global im Browserkontext existiert. Mit setItem und getItem
bietet es eine ähnliche Schnittstelle wie der Web Storage. Zusätzlich kann man, wie in Listing 3.13 gezeigt, die Domain
angeben, von der das Datum zugreifbar ist.
1
2
3
globalStorage [’’]. setItem ("i", 1);
globalStorage [’com ’]. setItem ("i", 1);
globalStorage [’example .com ’]. setItem ("i", 1);
// "i" global verfuegbar
// "i" in allen .com Domains verfuegbar
// "i" auf allen Subdomains von example .com verfuegbar
Listing 3.13: globalStorage Beispiele
Aus Sicherheitsgründen wurde die Möglichkeit global Daten abzulegen oder sie nur auf TLDs14 zu beschränken nie
implementiert [45]. So würde das Ablegen eines Datums auf globalem Geltungsbereich im besten Fall zu Verwirrung
führen, da jede Webanwendung darauf zugreifen und es ändern könnte. Und damit auch die von anderen abgelegten
Informationen, die der Autor dann in veränderter Form vorfindet.
Im schlimmsten Fall könnten kritische Informationen ausgelesen und verändert werden, wenn eine Webseite die Tatsache der globalen Gültigkeit übersieht und kritische Informationen dort ablegt. Der GlobalStorage wird in Firefox ab
Version 13 nicht mehr unterstützt [30]; er wurde vom Web Storage abgelöst. Die Daten werden ohnehin auf die gleiche
Art in einer Sqlite Datenbank15 persistent abgelegt, wie die Datenbank zeigt16 .
Cross-Tab Kommunikation
Die Webseite Badoo.com nutzt das Storage-Event, um alle geöffneten Fenster der Domain zu erkennen und einen
Kommunikationskanal zwischen ihnen aufzubauen. Dazu überwacht jedes Fenster den LocalStorage auf Änderungen
und reagiert auf das Setzen bestimmter Werte.
In Abbildung 3.8 ist Fenster 1 das Fenster, das eine Nachricht sendet (1) und dadurch die Kommunikation beginnt.
Fenster 2 steht für alle anderen geöffneten Fenster der Domain. Sie werden implizit adressiert, da das Storage-Event
automatisch vom Browser bei allen zum Origin passenden Kontexten ausgelöst wird. Nach dem Setzen eines beliebigen
Wertes werden alle anderen Fenster durch das Storage-Ereignis (1.1) über die Änderung informiert. Sie prüfen bestimmte,
von Badoo.com als Ereignis definierte Einträge des LocalStorage (hier: „Broadcast“) auf Änderungen. Wurde ein überwachter Eintrag verändert, wird ein entsprechendes Event mit dem abgelegten Wert als Nachricht („Nachricht“) ausgelöst
(1.1.1). Dabei ist hier kein DOM-Event gemeint, wie es das Storage-Event ist, sondern ein Ereignis der Implementierung
des Observer-Patterns [14] von Badoo.com.
Diese Interaktion könnte auch mit einem SharedWorker realisiert werden. Dafür müsste jedes Fenster auf einen gemeinsamen SharedWorker zugreifen und sich registrieren. Dann kann der Kontext eine Nachricht an den Worker senden.
Der SharedWorker würde anschließend die empfangene Nachricht an alle registrierten Kontexte weiterleiten, die darauf
reagieren können.
14
15
16
Top Level Domains
http://www.sqlite.org/
webappsstore.sqlite im Benutzerverzeichnis (http://kb.mozillazine.org/Profile_folder)
21
Die SharedWorker werden jedoch noch nicht von allen Browsern
unterstützt (siehe Tabelle 3.2), im Gegensatz zum LocalStorage, weshalb von Badoo.com diese Implementierung vorgezogen wurde. Von
der Implementierung geht keine Gefahr aus, denn der LocalStorage
wird durch die SOP geschützt. Somit kann keine Information an eine
fremde Domain übertragen werden.
Wie alle JavaScripte ist auch der Web Storage nicht vor XSS-Lücken
geschützt. Durch eine offene XSS-Schwachstelle hat ein Angreifer vollen Zugriff auf den Speicher, der ihm eine Plattform für einen persistenten XSS-Angriff bietet. Mit einem DNS-Spoofing-Angriff [11] kann
sich ein angreifendes Skript fälschlicherweise einem Origin zuordnen,
das Zugriff auf den Web Storage hat und ihn auf diese Art manipulieren. Weder XSS noch DNS-Spoofing sind HTML5 spezifische Attacken,
weshalb hier nicht näher darauf eingegangen wird. Die Konsequenzen aus diesen und weitere Angriffsvektoren werden im Folgenden
beschrieben.
Abbildung 3.8: Badoo.com:
Kommunikation
zwischen Fenstern
Tracking
Der LocalStorage bietet Web-Trackern eine weitere Möglichkeit identifizierende Tokens im Browser abzulegen. Da
der Web Storage in allen Implementierungen separat von den Cookies gelöscht werden muss, kann ein Tracker bei
der Löschung des einen Tokens auf den verbliebenen zurückgreifen und den gelöschten wiederherstellen. Nathan Good
konnte bereits eine Webseite identifizieren, die den LocalStorage für Tracking verwendet [32].
Cross-Directory Angriff
Alberto Trivero weist auf einen Cross-Directory Angriff hin [45], der es einem Angreifer ermöglicht,
die gespeicherten Informationen auszulesen.
Alle Werte, die Alice im Verzeichnis /alice auf
example.com im Web Storage ablegt (siehe Abbildung 3.9), sind global auf example.com sichtbar. So kann Bob, der Zugriff auf das Verzeichnis
/bob hat, auslesen, was Alice gespeichert hat. Dieses Problem tritt besonders bei Anbietern von Webspace auf, die diesen unter einer benutzerspezifischen URL verfügbar machen, wie in Abbildung 3.9
angedeutet. Ein Beispiel für einen solchen Anbieter ist MySpace17 . Diese Gefahr besteht nicht bei
der Verwendung von Subdomains. So kann Bob
von bob.example.com Alice’ Web Storage unter
alice.example.com nicht auslesen, da der Zugriff
durch die SOP verhindert wird.
In einem Web Storage könnten Datenschutz reAbbildung 3.9: Cross-Directory Angriff
levante Informationen abgelegt sein, die so leicht
von Angreifern ausgespäht werden können. Ebenfalls ist es möglich, Code im LocalStorage abzulegen, damit dieser nicht bei jedem Aufruf der Seite erneut heruntergeladen werden muss. Dies hat besonders Vorteile bei mobilen Geräten mit langsamer Internet-Verbindung.
Mallory kann mit dem Code in Listing 3.14 leicht interessante Werte im LocalStorage ausfindig machen. Findet er
Code, kann er ihn modifizieren und einen XSS-Angriff ausführen oder ungeschützte private Informationen abhören.
Die Spezifikation sieht diesen Zugriff über Verzeichnisse hinweg explizit vor, da selbst eine Beschränkung leicht umgangen werden kann [60]. Unwissende Programmierer sind dieser Gefahr ausgesetzt, wenn sie den Web Storage in einer
entsprechenden Umgebung verwenden.
17
22
http://www.myspace.com
1
2
3
4
for (key in localStorage ) {
// Gibt alle Elemente des localStorage im Format " Schluessel : Wert" aus
document .write(item + ": " + localStorage . getItem (key));
}
Listing 3.14: Auflistung aller Elemente im localStorage
Speichergrößen
Ein großer Nachteil an Cookies ist die Größenbeschränkung auf 4 KB, die heutigen Webanwendungen nicht mehr gerecht
wird. Das W3C empfiehlt den Web Storage in seiner Größe zu beschränken und schlägt als obere Grenze 5 MB vor [60].
Dieses Limit sollte pro Domain gelten, da sonst der Speicher von example.com durch Verwendung von Subdomains, wie
a1.example.com und a2.example.com, ohne Wissen des Benutzers, erhöht werden kann.
Dies steht im Widerspruch zu dem
in Abschnitt Cross-Directory Angriff
LocalStorage SessionStorage Cross-Domain Quota
Browser
beschriebenen Verhalten bei SubdoChrome
5 MB
5 MB
Nein
mains. Zum einen soll Bob a) kei5 MB
unbegrenzt
Ja
Firefox
nen Zugriff auf Alice’ LocalStorage
Internet Explorer
10 MB
10 MB
Ja
haben, zum anderen will man aber
5 MB
10 MB
Nein
Opera
b) verhindern, dass durch mehreSafari
5 MB
unbegrenzt
Nein
re Subdomains das Limit umgangen
wird. Option b) würde dazu führen,
Tabelle 3.5: Größe des Web Storage
dass Alice keinen Speicher mehr zur
Verfügung bekommt, wenn Bob in seiner Subdomain die vollen 5 MB verbraucht. Der Internet Explorer und Firefox führen diese Beschränkung tatsächlich auf Domain-Ebene ein; alle anderen Browser bieten für jede Sub-Domain neue Quota
an. Bei Ersteren könnte Mallory also bei jedem Besucher seiner Subdomain mallory.example.com den LocalStorage bis
zum Erreichen der Grenze beschreiben und auf diese Art verhindern, dass Alice’ oder Bobs Webseiten neue, größere
Werte ablegen können.
Tabelle 3.5 zeigt, dass alle Browser der Empfehlung des W3C folgen und den LocalStorage auf 5 MB begrenzen. Nur
der Internet Explorer fällt aus der Reihe und bietet 10 MB Speicherplatz [27].
Man muss aber beachten, dass verschiedene Browser die Daten auch in unterschiedlichem Format ablegen (meist
UTF-8 oder UTF-16), sodass ein Buchstabe ein oder zwei Byte Speicher benötigen kann [15]. Das führt dazu, dass eine
Webseite entweder 5 oder nur 2,5 Millionen Zeichen ablegen kann, wobei sich der Speicherverbrauch aus der Summe
der Größe der Schlüssel und Werte berechnet. Ein Entwickler kann sich daher nicht auf die Größe von 5 MB verlassen.
Bei intensiver Verwendung des LocalStorage durch eine Webanwendung ist also die kleinste Speichermenge (2,5 Millionen Zeichen) die obere Schranke, für die die Verfügbarkeit gesichert ist. Dazu ist die Speichergröße Schwankungen
unterworfen, da sie durch die Spezifikation nicht festgelegt wird. Das zeigt der Verlauf der Speichergrößen des OperaBrowsers [15]. Eine Webanwendung, die das nicht beachtet, kann bei vollem Speicher keine Daten mehr ablegen und
wird diese verlieren, falls keine Alternative implementiert ist.
Opera
Opera stellt mit 2,5 Millionen Zeichen den kleinsten Speicher. Allerdings bietet er als einziger die Möglichkeit den Speicher beim Überlauf zu vergrößern, wie vom W3C vorgeschlagen [60]. Dafür wird der Benutzer mit dem in Abbildung 3.10
gezeigten Dialog gefragt, ob der LocalStorage für ein Origin vergrößert werden darf. Der Dialog bietet die Möglichkeit den
Speicher weiterhin auf eine wählbare Größe zu beschränken
oder der Domain unbegrenzt Speicher zur Verfügung zu stellen. Für einen unerfahrenen Benutzer ist es schwer zu verstehen, was es bedeutet, dass eine Webseite mehr Speicherplatz
Abbildung 3.10: Opera benötigt mehr LocalStorage
benötigt. Er kann nicht einschätzen, welche Folgen die Erweiterung des Speichers hat und folglich keine begründete Wahl
treffen. Die meisten Benutzer wählen vermutlich die kleinste Erweiterung oder bieten der Webseite gleich unbegrenzten
Speicherplatz an.
Firefox und Opera bieten dem Benutzer sogar die Möglichkeit über about:config und opera:config die Standardgröße anzupassen [44], was eine gewisse Erfahrung voraussetzt. Opera bietet zudem über das URI Schema
opera:webstorage (siehe Abbildung 3.11) die Möglichkeit, die Größe pro Domain einzustellen, zu löschen oder das
23
Nachfragen zu verbieten. Die weitere Entwicklung von HTML wird zeigen, ob sich 5 MB als Größe etabliert und der
Benutzer die Möglichkeit hat, diese zu erweitern.
Abbildung 3.11: opera:webstorage
SessionStorage
Der Vorschlag zur Beschränkung auf 5 MB schließt auch den SessionStorage ein. Da der SessionStorage beim Beenden des Kontextes gelöscht wird, bieten Firefox und Safari aber sogar unbegrenzt Speicher an (siehe Tabelle 3.5). Die
Daten werden nicht auf die Festplatte in die webappsstore.sqlite-Datenbank geschrieben, sondern ausschließlich im
Arbeitsspeicher gehalten. Ein Angreifer kann hier weniger Schaden anrichten als im LocalStorage. Ein möglicher persistenter XSS-Angriff wäre auf eine Browsersitzung beschränkt, zudem ist der SessionStorage unabhängig vom Kontext,
was den Angriff zusätzlich nicht aus dem aktuellen Fenster ausbrechen lässt. Der LocalStorage wirkt daher für Angriffe
attraktiver.
Integrität
Ein Blick in Firefox’ webappsstore.sqlite legt offen, dass bereits einige Webseiten und insbesondere der InternetDienstleister Cloudflare18 JavaScript-Objekte und Code im LocalStorage speichern.
So auch das von Mozilla entwickelte Spiel Browserquest19 , das die Leistungsfähigkeit der neuen Elemente von HTML5
demonstrieren soll. Es bietet mehreren Benutzern die Möglichkeit, interaktiv im Browser zu spielen, während die Logik
und die Grafik keine Plugins mehr benötigen, sondern auf die neuen Elemente von HTML5 zurückgreifen. So kommen hier WebSockets, Web Worker und natürlich der LocalStorage zu Einsatz [29]. Um den persönlichen Spielstand zu
repräsentieren, wird der Datensatz in Listing 3.15 unter dem Schlüssel data gespeichert
Verändert man diesen Datensatz, kann man sich Errungenschaften („achievements“) oder bessere Waffen erschleichen,
die dann beim nächsten Start des Spieles zur Verfügung stehen. Dafür muss man nur die entsprechenden Indizes für
freigeschaltete Errungenschaften in Zeile 9 ergänzen oder den Wert „goldensword“ in Zeile 5 durch die gewünschte
Waffe ersetzen.
1
2
3
4
5
6
7
8
9
10
11
12
{
" hasAlreadyPlayed ":true ,
" player ":{
"name":"Mq",
" weapon ":" goldensword ",
...
},
" achievements ": {
" unlocked ":[4 ,1 ,11 ,5 ,3 ,2 ,7 ,19 ,6 ,18 ,9 ,10 ,12 ,8 ,16 ,17 ,13 ,20 ,15 ,14] ,
...
}
}
Listing 3.15: Browserquest Speicherdatum
18
19
24
http://www.cloudflare.com/
http://browserquest.mozilla.org/
In diesem Beispiel hat der Betrug keine weiteren Auswirkungen, außer dass der Spielspaß verloren geht. Es zeigt jedoch
deutlich, dass die Integrität der Daten nicht geschützt ist. Es gibt die Möglichkeit, den Storage direkt im Dateisystem
zu verändern. Einige Browser besitzen auch eine JavaScript-Konsole, über die man beliebige Modifikationen am DOM
vornehmen kann, um nur zwei Methoden für den Benutzer zu nennen. Ein Angreifer könnte über eine XSS-Lücke Daten
oder Code verändern.
Gefahr birgt der LocalStorage, da eine reflektierte XSS-Attacke durch ihn persistent gemacht werden kann. Dadurch
bleibt der Angriff bestehen, solange der Storage nicht gelöscht oder repariert wird, auch wenn die eigentliche (reflektierte) Lücke geschlossen wird. Außerdem wird der Schadcode potentiell auch auf weiteren Teilen der Domain, die nicht
von einer Lücke betroffen sind, ausgeführt, wenn sie auf das infizierte Element des Storage zugreifen [23].
Wie beschrieben kann der LocalStorage auch als Cache für Code benutzt werden. Der JavaScript-Code, der zum Beispiel von Cloudflare abgelegt wird, hat eine beträchtliche Größe von rund 176.000 Zeichen. In dieser Größenordnung ist
Schadcode, ob absichtlich eingefügt oder nicht, kaum von Hand von integerem Code zu unterscheiden. Der Web Storage
bietet weder eine Möglichkeit, einen Integritätscheck durchzuführen, noch stellt er sie selbst sicher. Ein Webentwickler
muss diese Situation bei der Implementierung bedenken.
Da der Code im LocalStorage meist mit dem Ziel abgelegt wird, wiederholte Übertragungen zu vermeiden, sollte ein
Integritätscheck diesen Aspekt beachten. Dem Webserver ist der Inhalt des Codes bekannt, sodass er eine Prüfsumme bilden kann. Anschließend kann er ein kurzes Codestück senden, das eine Prüfsumme über den im LocalStorage abgelegten
Code bildet, und so Änderungen auf Clientseite feststellen. Auf diese Art kann die Angriffsfläche verringert werden, denn
das Manipulieren des Prüfcodes, der nicht im Storage liegt, ist bedeutend schwieriger auszuführen.
Der Web Storage wird den Anforderungen moderner Webseiten nach mehr Speicherplatz gerecht. Auch wenn Widersprüche in der Größe und Verteilung des Web Storage auf Subdomains auftreten, ist er durch die SOP ausreichend
abgeschirmt. Entwickler müssen sich der Gefahr durch die mögliche Persistierung von Angriffen bewusst sein und können bei Bekanntwerden einer Lücke reagieren und den Speicher bei den Clients löschen und die integeren Werte wieder
eintragen. Der lokale Speicher ist geschützt, solange die gesamte Webseite vor XSS-Angriffen geschützt ist, was das Ziel
jedes Entwicklers sein sollte. Das Tracking stellt kein Problem dar, da hier mit dem Do-Not-Track Header an anderer Front
ein Standard geschaffen wird, siehe dazu [55].
25
3.5 Cross-Origin Resource Sharing
Da sich die SOP im modernen Internet als zu restriktiv für einige Anwendungen herausstellte, gibt es einige Möglichkeiten trotzdem Ressourcen von fremden Domains zu laden. Der Vorreiter war Adobe mit dem Flash-Plugin, dem dies per
crossdomain.xml erlaubt werden konnte. Weitere Möglichkeiten, wie Microsoft Silverlight20 und Google Gears21 , folgten.
Wie bereits beim Web Messaging entsteht durch MashUps, die Dienste von verschiedenen Anbietern und Domains
kombinieren, eine Vielzahl an spezifischen Möglichkeiten, die die Notwendigkeit an dieser Stelle einen Standard zu
etablieren schaffen. Was durch CORS des W3C geschieht. CORS reguliert die Ausnahme von der SOP, die es erlaubt
Ressourcen von einer fremden Domain zu laden.
3.5.1 Spezifikation
Bisher war asynchrone Kommunikation mit JavaScripts XHR durch die SOP auf
die selbe Domain beschränkt. Die CORS-Spezifikation [48] erweitert den XHR um
Browser
CORS
die Möglichkeit, für jede Ressource genau zu bestimmen, von welchem EmpfänChrome
Ja
ger sie angefragt werden kann. Genau genommen ist CORS kein Teil der HTML5Firefox
Ja
Spezifikation, wird jedoch in vielen Publikationen in diesem Zusammenhang erInternet Explorer ab Version 10
wähnt, da es hauptsächlich mit weiteren Technologien des modernen Webs zum
Ja
Opera
Einsatz kommt, so zum Beispiel mit den Server-Sent Events, die in Abschnitt 3.8.2
Safari
Ja
vorgestellt werden.
Tabelle 3.6: Unterstützung CORS
An der Implementierung der Client-Seite (Konsument, Abbildung 3.12) von
Webanwendungen ändert sich durch CORS nichts, die HTTP-Requests von JavaScript bleiben unverändert. Lediglich ein XHR an eine fremde Domain wird nun ausgeführt, was zuvor fehlschlug.
Der Browser führt die Anfrage an eine fremde Domain (Ressource, example.com) durch, indem er zusätzlich im
Origin-Header die Domain, die die Anfrage sendet, übermittelt (other.com). Der Server der Ressource kann nun überprüfen, ob er dem Empfänger vertraut und mit dem Access-Control-Allow-Origin-Header dem Browser mitteilen, für
welche Domain die Anfrage erlaubt ist. Stimmt die per Header übertragene Domain mit dem Origin der Anfragenden
überein, wird die Antwort auf den Request an den Kontext des aufrufenden XHR übergeben, der nun erfolgreich eine
Cross-Origin Anfrage durchgeführt hat.
1
2
3
4
5
6
Access -Control -Allow - Origin : http :// other.com
Access -Control -Allow - Origin : *
// Zusaetzliche Header
Access -Control -Allow - Credentials : true
Access -Control -Expose - Headers : X-Powered -By , Server
Listing 3.16: CORS Header
Die Ressource stellt also die Policy bereit, die festlegt, wer Zugriff bekommt. Der Policy Enforcement Point, der die
Einhaltung der Regel gewährleistet, ist der Browser des Benutzers. Durch den Vergleich des Headers mit dem Origin
entscheidet er, ob die Information der Ressource ausgeliefert wird oder nicht.
20
21
26
http://www.microsoft.com/silverlight/
2011 eingestellt: http://gearsblog.blogspot.de/2011/03/stopping-gears.html
Abbildung 3.12: CORS
Die Ressource hat die Möglichkeit über weitere Header genau zu bestimmen welche Informationen vom Browser an
das Skript weitergereicht werden dürfen. So kann sie mittels Access-Control-Allow-Credentials festlegen, ob Anfragen mit Credentials weitergegeben werden dürfen. Credentials können Cookies oder weitere Header sein, die zur
Benutzeridentifikation dienen und damit personalisierte oder private Informationen vor fremdem Zugriff schützen. Standardmäßig werden Cookies bei einem Cross-Domain Request nicht mitgesendet. Das muss zunächst mit dem Schalter
XMLHttpRequest.withCredentials = true aktiviert werden, wodurch der Konsument der Übermittlung von Credentials zustimmt. Die Einwilligung erfolgt also auf Server- und Client-Seite.
Mit dem Access-Control-Expose-Headers-Header kann die Ressource entscheiden, welche Header an die fremde Domain des Konsumenten übergeben werden dürfen. Das gilt jedoch nicht für die Simple Header Cache-Control,
Content-Language, Content-Type, Expires, Last-Modified und Pragma. Diese werden immer übergeben, alle anderen müssen mit dem Access-Control-Expose-Headers-Header erlaubt werden.
CORS ermöglicht einen ähnlichen Anwendungsfall, wie Web Messaging im Szenario von Facebook Connect (siehe
Abschnitt 3.1.3). Mit dem Unterschied, dass bei CORS keine Webseite der Ressource als Proxy dient, sondern die Kommunikation direkt erfolgt. Die Ressource hat damit allerdings auch nicht die Möglichkeit selbst, in einem IFrame mit dem
Anwender in Dialog zu treten, um ihm beispielsweise Auswahlmöglichkeiten anzubieten.
Bei Flash und Silverlight, den Vorläufern von CORS, treten einige Probleme auf, die bei unbedachter Verwendung zu
Sicherheitsrisiken werden [25]. Dieser Abschnitt analysiert, wie CORS versucht diese zu verhindern.
Credentials
Sitzungen, die eine Authentifikation erfordern, um personalisierte oder private Daten anzuzeigen, werden mittels
Cookies vom Server unterschieden. Diese Methode ist notwendig, da HTTP ein zustandsloses Protokoll ist und daher
diese Information nicht aus dem Protokollfluss hervorgeht.
Bei Anfragen mit Flash wird das Sitzungscookie (Credentials) automatisch übertragen, was Angreifern die Möglichkeit
zum Session-Hijacking gibt. Das entspricht Platz 3 der OWASP Top 10 [72].
Bei CORS sind solche Credentials durch drei Mechanismen geschützt:
1. Es werden standardmäßig keine Credentials versendet. Der Konsument muss den Browser explizit mit dem Aufruf
XMLHttpRequest.withCredentials = true beauftragen, diese an den Cross-Origin Request anzuhängen.
2. Die Antwort auf einen solchen Request wird nur an den Konsumenten weitergeleitet, wenn auch die Ressource, die
der Aussteller der Credentials ist, dem zustimmt. Das geschieht über den Access-Control-Allow-CredentialsHeader. Eine Antwort, die diesen nicht enthält, aber mit Credentials angefragt wurde, wird vom Browser nicht
weitergeleitet.
3. Ein Header mit den Credentials wird nicht automatisch an den Konsumenten übergeben, da es kein Simple Header
ist (siehe 3.5.1). Bei Cookie basierten Sessions müsste der Set-Cookie-Header weitergegeben werden, um für
Session-Hijacking anfällig zu sein, was standardmäßig nicht passiert.
27
Der Inhalt des Session-Cookies kann zwar an den Server übertragen werden, wird aber ohne seine Einwilligung niemals an den Konsumenten ausgeliefert. Dieser erhält nur die Antwort des Servers, die möglicherweise personalisierte
Informationen enthält. Da dem Server aber bekannt ist, welche (fremde) Domain die Informationen erhält, kann er bei
einem Risiko auch auf die Beantwortung des Requests verzichten.
Bösartige Ressource
Als Konsument muss man sich bewusst machen, dass auch die Ressource, die man verwendet, entweder durch Absicht oder durch einen Angriff, bösartig werden kann. Mögliche Gefahren sind daher das ungeprüfte Ausführen von
empfangenem Code mit eval() oder setTimeout(), was die Tür für einen XSS-Angriff öffnet.
Cross-Site Request Forgery
Mit einem CSRF-Angriff versucht Mallory, HTTP-Requests abzusenden, um den Zustand von Alice’ Sitzung bei ihrer
Online-Bank zu verändern, sodass eine Überweisung auf sein Konto erfolgt. CSRF rangiert auf Platz 5 der häufigsten
Angriffe auf Webanwendungen [72]. Eine gängige Abwehrmethode sind Tokens, ein String von Zufallswerten, der an
Alice gesendet wird, um ihre nächste Anfrage zu autorisieren.
Das Token ist meist Inhalt der übertragenen Seite, wird also sowohl mit dem Vorläufer Flash, wie auch mit CORS
an den Konsumenten übergeben, wenn ein Cross-Domain Request auftritt. Das hat zur Folge, dass Mallory von einer
beliebigen Domain XHR-Anfragen an Alice’ Bank verschicken kann, um an das Token zu gelangen. Der Vorteil von CORS
an dieser Stelle ist, dass die Policy, wer Zugriff bekommt, nicht von der angeforderten Ressource entkoppelt ist. Während
bei Flash parallel die crossdomain.xml heruntergeladen wird, um die Richtlinie durchzusetzen, kann der Server bei
CORS durch die Existenz des Origin-Headers erfahren, dass es sich um einen Cross-Domain Aufruf handelt. Somit ist es
möglich, eine echte Sitzung in einem Browserkontext laufen zu lassen, während parallel CORS-Anfragen ohne Sitzung
und Zustandsänderung auf Server-Seite beantwortet werden können.
Im Wesentlichen ist also bei der Entwicklung von Webanwendungen mit CORS darauf zu achten, dass ein Cross-Origin
Request keine ungewollten Seiteneffekte auslöst.
Wildcard
Bei Flash und Silverlight stellte die Benutzung der Wildcard „*“ ein Problem dar, was bei etwa 18 % der Alexa TOP
1.000.00022 Webseiten, die crossdomain.xml verwenden, zu einem Sicherheitsrisiko führt [25].
Bei CORS ist ein Sicherheitsmechanismus eingebaut, der verhindert, dass die Wildcard und der Access-Control-AllowCredentials-Header in der selben Anfrage benutzt werden. Eine solche Anfrage darf vom Browser nicht weitergeleitet
werden, um personalisierte Daten nicht versehentlich an eine fremde Domain auszuliefern.
Die Spezifikation gibt zusätzlich genaue Richtlinien, wann ein Wildcard-Header anwendbar ist. Dazu gehört der Fall
von ohne Beschränkung zugänglichen Seiten oder JavaScript Dokumenten, die ohnehin per <script>-Tag über Domains
hinweg geladen werden können [48]. An anderer Stelle sollte aus Sicherheitsgründen immer auf die Wildcard verzichtet
werden, damit kein Angreifer an sensible Informationen gelangen kann.
Reverse Web Shell
Die extremste Form eines Angriffes mittels CORS wurde 2010 von andlabs.org vorgestellt [4].
Eine XSS-Lücke oder ein präparierter Link ermöglichen die Injektion des Codes der Reverse Web Shell. Die Shell gibt
dem Angreifer die Möglichkeit ferngesteuert beliebige HTTP- und HTTPS-Request im Namen des Opfers auszuführen.
Dafür fragt der Schadcode per CORS auf dem Server des Angreifers regelmäßig den nächsten Befehl ab und führt ihn
anschließend aus.
Der Angreifer kann damit den Browser vollständig übernehmen und fernsteuern. Er kann beliebige Requests absetzen
und damit besonders in aktive Sitzungen, die eine Authentifizierung benötigen eingreifen. Der Angreifer kann in den
laufenden Sitzungen des Opfers Nachrichten, Bankdaten oder andere kritische Informationen einsehen und bearbeiten.
CORS bildet die Grundlage für die neuen Kommunikationsmöglichkeiten von HTML5. Es stellt ein Protokoll bereit,
mit dem Browser und Server das Laden von Cross-Domain Ressource kontrollieren und gegen unbefugten Zugriff schützen können. Dabei kommt CORS nicht nur beim XHR Level 2 zum Einsatz, sondern auch bei den später vorgestellten
WebSockets und den Server-Sent Events, um auch diese zwischen verschiedenen Domains zu ermöglichen.
22
28
http://www.alexa.com/topsites
3.6 WebSocket API
Moderne Webanwendungen begnügen sich nicht mit den eingeschränkten Kommunikationsmöglichkeiten unter der
SOP vor HTML5. CORS ermöglicht die asynchrone Anfrage eines Clients an einen Server einer anderen Domain. Die
bidirektionale Interaktion zwischen zwei Kontexten wird durch Web Messaging realisiert. Analog dazu gibt es bei HTML5
mit den WebSockets die Möglichkeit, bidirektionale Verbindungen mit einem Server aufzubauen. Eine HTTP Anfrage geht
bisher immer vom Client aus, sodass vom Server gesendete Nachrichten durch Polling simuliert wurden.
3.6.1 Spezifikation
Das WebSocket Protokoll setzt direkt auf dem TCP23 auf, um einen DuplexKanal zwischen Client und Server aufzubauen. Diese Verbindung bleibt geBrowser
WebSocket API
öffnet, im Gegensatz zum Polling, bei dem für jede Anfrage eine neue VerChrome
ja
bindung aufgebaut werden musste. Das Protokoll wurde von der Internet
ja
Firefox
Engineering Task Force im RFC 6455 spezifiziert [13] und wird von der W3C
Internet Explorer
nein
Spezifikation referenziert, die die Schnittstelle im Browser beschreibt [62].
Opera
nein
Um das HTTP und das WebSocket Protokoll parallel auf einem Server
Safari
ja
nutzen zu können, wurde der Verbindungsaufbau als Upgrade der HTTPTabelle 3.7: Unterstützung WebSockets
Verbindung realisiert. Dazu sendet der Browser die HTTP-Header Upgrade:
websocket und Connection: Upgrade (siehe Listing 3.17), um dem Server
den Wechsel auf das WebSocket Protokoll zu signalisieren. Der Server antwortet mit dem HTTP-Status 101 und den
beiden Headern, um den Protokollwechsel zu akzeptieren (Listing 3.18). Mit den Headern Sec-WebSocket-Protocol
und Sec-WebSocket-Version können selbst definierte Subprotokolle an den Server mitgeteilt und die Version des WebSocket Protokolls bestimmt werden. Version 13 entspricht der aktuellen Spezifikation in RFC 6455. Die Funktion des
Sec-WebSocket-Key- und Sec-WebSocket-Accept-Headers werden in Abschnitt Handshake erläutert.
Nach dem Empfang der Antwort vom Server erfolgt die Kommunikation über das WebSocket Protokoll, das nur minimale Zusatzinformationen (16 - 114 bit) zu den übertragenen Informationen hinzufügt und deshalb einen Vorteil
gegenüber HTTP bietet.
1
2
3
4
5
6
7
8
GET /chat HTTP /1.1
Host: server . example .com
Upgrade : websocket
Connection : Upgrade
Sec -WebSocket -Key: dGhlIHNhbXBsZSBub25jZQ ==
Origin : http :// example .com
Sec -WebSocket - Protocol : chat , superchat
Sec -WebSocket - Version : 13
Listing 3.17: Client Handshake [13]
1
2
3
4
5
HTTP /1.1 101 Switching Protocols
Upgrade : websocket
Connection : Upgrade
Sec -WebSocket - Accept : s3pPLMBiTxaQ9kYGzzhZRbK +xOo=
Sec -WebSocket - Protocol : chat
Listing 3.18: Server Handshake [13]
Im Browser kann eine WebSocket-Verbindung über den Konstruktor new WebSocket(url, protocols) aufgebaut werden. Der Parameter url ist dabei die URL, mit der die Verbindung aufgebaut werden soll. Die Spezifikation sieht zwei
Protokoll-Schemata vor: ws:// und wss://. Ersteres ist das einfache WebSocket-Protokoll und letzteres, analog zu HTT23
Transmission Control Protocol
29
PS, die durch SSL24 getunnelte Variante (siehe Abschnitt Integrität und Vertraulichkeit). Mit protocols können die
Subprotokolle bestimmt werden, die dann per Header an den Server gesendet werden.
Bei dem Socket-Objekt können Listener für die vier Events open, error, close und message registriert werden. Mit
WebSocket.onmessage(event) reagiert man auf ankommende Nachrichten des Servers, die in event.data bereit stehen
(siehe Listing 3.19), wie zuvor im Kapitel Web Messaging beschrieben.
Durch die Methode send(), die das WebSocket-Objekt bereitstellt, können Nachrichten an den Server gesendet werden. Dabei muss allerdings beachtet werden, dass der Verbindungsaufbau einige Zeit benötigt. Erst wenn die Verbindung
bereit ist, was durch das Feuern des open-Events angezeigt wird, können Nachrichten übertragen werden.
1
2
3
4
5
6
var socket = new WebSocket ("ws :// socket . example .com");
socket . onmessage = function (event) {
// verarbeite event
}
socket .send(" Nachricht ");
Listing 3.19: Verwendung des WebSockets
Die send-Methode ist mit den Typen String, Blob25 und ArrayBufferView26 überladen. Die JavaScript-Typen werden
auf die Protokoll Frame Typen Text und Binary übertragen. Es gibt noch weiter Frame Typen, wie Ping und Pong, die zum
Testen und Halten der Verbindung genutzt werden. Sie werden jedoch nicht in der JavaScript API verwendet.
Handshake
Um zu verhindern, dass Angreifer per XHR oder Formularen eine Verbindung zu einem WebSocket aufbauen, sendet
der Browser den Header Sec-WebSocket-Key an den Server. Der Wert dieses Headers ist die Base64-Kodierung27 eines zufällig gewählten, 16 Byte großen Wertes. Der Server muss diesen Wert mit einer GUID28 konkatenieren und die
wiederum Base64 kodierte SHA-1 Prüfsumme29 im Sec-WebSocket-Accept-Header an den Browser zurücksenden. Ist
der Header nicht vorhanden oder der Wert falsch, muss der Browser davon ausgehen, dass der kontaktierte Server das
WebSocket Protokoll nicht versteht. Die Verbindung wird unterbrochen.
Integrität und Vertraulichkeit
Das WebSocket-Protokoll und die WebSocket API besitzen keine eigenen Mittel, um die Schutzziele Integrität und
Vertraulichkeit herzustellen. Diese lassen sich jedoch leicht über einen SSL-Tunnel erreichen, indem man statt des ws://Handlers den wss://-Handler bei der Initialisierung des Sockets verwendet.
Protocol Upgrade
Im Jahr 2010 wurde von Adam Barth eine Lücke im WebSocket-Protokoll entdeckt [7]. Durch entsprechende Nachrichten konnte der Cache eines Proxy-Servers mit falschen Inhalten befüllt werden. Nach dem Upgrade auf das WebSocket
Protokoll sendete der Client Nachrichten, die für einen Proxy, der WebSocket nicht kennt, wie HTTP GET-Requests aussehen. Der Websocket-Server antwortete anschließend mit dem Inhalt, mit dem der Angreifer den Cache vergiften möchte.
War zuvor die gefälschte GET-Anfrage an populäre JavaScript Bibliotheken, wie Google Analytics30 , gerichtet, wurde nun
das maliziöse Skript im Cache abgelegt. Allen Nutzern dieses Caches wurde fortan der Schadcode statt des gewünschten
Skriptes ausgeliefert.
Um solche Angriffe zu verhindern, werden alle vom Browser gesendeten Nutzdaten maskiert. Dazu wird für jede
Nachricht vom Browser an den Server ein 32 bit Schlüssel generiert, der als Header ebenfalls übertragen wird. Die
Maskierung findet durch XOR-Verknüpfung der Nachricht mit dem Schlüssel statt. Diese Maßnahme ist sicher, solange
ein Angreifer per JavaScript API keinen Zugriff auf den Schlüssel hat und diesen auch nicht vorherbestimmen kann. Da für
jede Nachricht ein neuer Schlüssel verwendet wird, kann der Angreifer auch keinen Known-Plaintext-Angriff ausführen,
da dieser keine Aussagen über den Schlüssel der nächsten Nachricht zulässt.
Ein Angreifer kann durch die Maskierung nicht bestimmen, wie seine Nachricht aussehen muss, um seine WebSocket
Nachricht nach dem Maskieren, für Proxys ohne WebSocket Protokoll, wie eine GET-Anfrage aussehen zu lassen.
24
25
26
27
28
29
30
30
Secure Socket Layer
https://developer.mozilla.org/en/DOM/Blob/
https://developer.mozilla.org/en/JavaScript_typed_arrays/ArrayBufferView
http://tools.ietf.org/html/rfc4648
Globally Unique Identifier, http://tools.ietf.org/html/rfc4122, hier: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11
http://tools.ietf.org/html/rfc3174
http://www.google-analytics.com/
Cross-Domain
Die WebSocket API unterliegt nicht den Beschränkungen der SOP. Eine Verbindung kann zu jedem beliebigen Webserver aufgebaut werden, ohne Rücksicht auf Domains zu nehmen, solange das Handshake-Protokoll korrekt ausgeführt
wird. Um eingehende Verbindungen von unerwünschten Domains zu verhindern, ist der Browser verpflichtet den
Origin-Header beim Handshake mitzusenden. Der Server kann nun leicht anhand des Wertes entscheiden, ob er den
Verbindungsaufbau mit einer korrekten Antwort bestätigt oder durch eine HTTP-Fehlermeldung ablehnt.
IP- und Portscan
Durch WebSockets hat ein Angreifer die Möglichkeit, einen IP- und Portscan hinter der Firewall des privaten Netzwerkes seines Opfers durchzuführen. Eine Implementierung wurde 2010 von Lavakumar Kuppan präsentiert31 . Kuppan
scannte IP-Adressen oder Ports. Durch die verschiedenen Antwortzeiten konnte er bestimmen, ob ein Port offen oder
geschlossen ist und, ob eine IP-Adresse verwendet wird oder nicht. Dadurch konnte er die Topologie eines Netzwerkes auch hinter einer Firewall bestimmen, wenn ein Teilnehmer des Netzwerkes eine präparierte Webseite besucht. Die
Proof-of-Concept-Implementierung ist bis heute funktionsfähig.
Die WebSocket API baut einen Duplex-Kanal zu einem Webserver auf, was vor HTML5 durch Polling simuliert werden
musste. Dabei sind Client und Server durch die beschriebenen Mechanismen vor Angreifern ausreichend geschützt, sodass
eine Verbindung zwischen einem Client und einem Server nur dann aufgebaut werden kann, wenn sie tatsächlich von
der JavaScript API angefordert und vom Server unterstützt wird.
31
http://www.andlabs.org/tools/jsrecon/jsrecon.html
31
3.7 Offline Web Applications
Mit den Offline Web Applications bekommen Entwickler die Möglichkeit zu bestimmen, welche Teile ihrer Anwendungen
nicht erneut heruntergeladen werden müssen, sondern vom Cache des Browsers geholt werden können. Das spart zum
einen Bandbreite und, was vor allem bei mobilen Geräten von Bedeutung ist, macht Webseiten ganz ohne Verbindung
zum Internet nutzbar. Der Entwickler kann dafür, in einer Cache Manifest genannten Datei, festlegen, welche Teile seiner
Applikation zwischengespeichert werden sollen. Im folgenden wird die Benutzung des Application Caches vorgestellt und
die Probleme, die sich daraus ergeben.
3.7.1 Spezifikation
Browser
Chrome
Firefox
Internet Explorer
Opera
Safari
Offline Web Applications
ja
ja
nein
ja
ja
Tabelle 3.8: Unterstützung Offline Web Applications
Durch das Attribut manifest im Wurzel-Tag (<html>) eines HTMLDokumentes kann der Entwickler eine Manifest Datei bestimmen (siehe Listing 3.20) [52]. Mit dem Internet Explorer ab Version 10 werden
Offline Web Applications von allen Browsern unterstützt (Tabelle 3.8).
Das Manifest selbst muss als erste Zeile den String „CACHE MANIFEST“ enthalten. Nachfolgend wird die Datei in drei Abschnitte
eingeteilt, die durch die Überschriften „CACHE:“, „FALLBACK:“ und
„NETWORK:“ gekennzeichnet sind (Beispiel in Listing 3.21). Die Datei
muss vom Webserver mit dem MIME-Type32 text/cache-manifest
ausgeliefert werden. Alle nachfolgenden Instruktionen werden der
entsprechenden Sektion zugeordnet, wobei die Überschriften auch
mehrfach vorkommen dürfen.
• CACHE: Alle hier – mit relativen oder absoluten URLs – aufgeführten Dateien werden im Cache gespeichert und
für diese Domain fortan von dort geladen. Der erste Abschnitt im Manifest wird auch ohne diese Überschrift dieser
Sektion zugeordnet.
• FALLBACK: Hier müssen zwei URLs angegeben werden. Falls die erste nicht erreichbar ist, wird stattdessen die
Datei angezeigt, die als zweite URL referenziert wird.
• NETWORK: Bei hier aufgeführten Präfixen von URLs wird immer versucht diese herunter zu laden.
1
2
3
4
5
6
7
8
9
<! doctype html >
<html manifest =" manifest . appcache ">
<head >
<title >Ein HTML5 Dokument </title >
</head >
<body >
</body >
</html >
1
2
3
4
5
6
7
8
9
10
11
12
13
CACHE MANIFEST
# Die Bibliothek muss nicht erneut geladen werden
CACHE :
/lib.js
# Wenn offline , zeige offline -Bild
FALLBACK :
/ image .png / offline .png
# Wird immer Online angefragt
NETWORK :
/api
Listing 3.20: Verwendung des Manifestes
32
32
Multipurpose Internet Mail Extensions http://tools.ietf.org/html/rfc2045
Listing 3.21: manifest.appcache
Über das status-Attribut des window.applicationCache-Objektes lässt sich feststellen, in welchem der sechs Zustände sich der Cache gerade befindet:
• UNCACHED Es wurde kein Manifest angegeben.
• IDLE Es existiert ein aktueller Cache.
• CHECKING Es wird geprüft, ob aktuellere Versionen der gecacheten Dateien vorliegen.
• DOWNLOADING Aktuellere Versionen werden heruntergeladen.
• UPDATEREADY Eine aktualisierte Datei wurde heruntergeladen.
• OBSOLETE Es existiert ein Cache, der als obsolet markiert wurde und daher nicht verwendet wird.
Mit den Events updateready, checking und weiteren informiert der Browser die Webapplikation über Änderungen
am Status des Caches [52].
Mit der update-Methode lässt sich manuell auf Updates des Caches prüfen, was beim Laden der Seite automatisch
geschieht. Ein Update wird jedoch nur dann erkannt, wenn sich der Inhalt des Cache-Manifestes selbst ändert. Auf
Änderungen im Original einer bereits gecacheten Datei wird nicht geprüft und daher auch kein Update ausgelöst. Die
abort-Methode bricht das laufende Herunterladen von Aktualisierungen ab und mit der swapCache-Methode wird eine
heruntergeladene Aktualisierung aktiviert, sodass beim nächsten Laden der Seite der neue Cache verwendet wird.
1
2
3
4
5
6
var cache = window . applicationCache ;
cache. update () // Pruefe auf Aktualisierungen
cache. onupdateready = function (event) {
// Update verfuegbar
}
Listing 3.22: Application Cache Beispiele
Unsicheres Netzwerk
Die Nutzung des Application Caches eröffnet Mallory eine neue Angriffsmöglichkeit, die 2010 von Lavakumar Kuppan
beschrieben wurde [3]. Für den Angriff muss Mallory gefälschte Webseiten an Alice ausliefern können, wie es in einem
ungesicherten WLAN33 möglich ist. Er bringt Alice dazu, auf die Seite zu navigieren, die er angreifen möchte. Dazu schiebt
er ihr eine Webseite mit einem IFrame unter, das diese Seite als Ziel hat. Auf den darauf folgenden Request an die Zielseite
antwortet Mallory mit seiner gefälschten Seite, die das manifest-Attribut enthält, wodurch die Seite im Application Cache
gespeichert wird. Es wird nun, statt der echten Seite, die im Cache gespeicherte, gefälschte ausgeliefert.
Die gefälschte Zielseite kann dem Login-Formular zum E-Mail- oder Online-Banking-Account des Originals nachempfunden sein und Code enthalten, um die Anmeldeinformationen zu stehlen. Solche Seiten werden meist über HTTPS
ausgeliefert, jedoch achten die meisten Nutzer beim Eingeben der Adresse nicht auf das Protokoll, sodass eine Umleitung
von HTTP nach HTTPS von Nöten ist. Deshalb reicht es, die über HTTP ausgelieferte Seite zu fälschen, um Alice dazu zu
bringen dort ihre Daten anzugeben, da diese natürlich keine Weiterleitung zu HTTPS durchführt.
Gegenüber dem normalen Cache hat der Application Cache für Mallory den Vorteil, dass er explizit durch den Benutzer gelöscht werden muss und nicht durch Tastenkombinationen oder Regeln automatisch vom Browser geleert wird.
Dadurch bleiben die Opfer einer solchen Attacke länger infiziert.
Um den Vorteil der langen Persistenz des Application Caches zu nutzen, muss Mallory dafür sorgen, dass beim Laden
der Manifest Datei der Server keinen Fehler Typ 404 zurückgibt, die Datei also nicht gefunden werden konnte. Sonst
würde der Cache nicht mehr verwendet und die echte Datei aus dem Internet heruntergeladen. Da die Manifestdatei der
SOP unterliegt, hat er außerhalb des unsicheren Netzwerkes nicht mehr die Chance, Alice ein Manifest zu präsentieren.
Mallory muss deshalb eine beliebige Datei in der Domain der Zielseite verlinken, denn Dateien, die nicht mit CACHE
MANIFEST beginnen, werden ignoriert. Es wird also eine ungültige Cache-Datei heruntergeladen und die gefälschte
Datei verbleibt im Cache, da sie durch das manifest-Attribut implizit gecachet wird.
Eine Hürde bei diesem Angriff wird im Abschnitt Benutzerinteraktion beschrieben.
33
Wireless Local Area Network
33
Benutzerinteraktion
Bei der Benutzerinteraktion werden von den Browsern zwei Modelle verfolgt: keine Interaktion und „Frage den
Benutzer“. Chrome und Safari lassen dem Benutzer keine Möglichkeit, den Application Cache zu steuern. Über
chrome://appcache-internals/ können erfahrene Benutzer des Chrome-Browsers den Inhalt des Caches ansehen und
löschen.
(a) Firefox
(b) Opera
Abbildung 3.13: Browser bitten um Erlaubnis für Application Cache
Firefox und Opera fragen den Benutzer um Erlaubnis (Abbildung 3.13), wenn Webseiten den Application Cache benutzen möchten. Ein aufmerksamer Benutzer könnte durch eine solche Meldung misstrauisch werden und durch einen
Klick auf „Nie für diese Website“ oder „Niemals“ einen Angriff, wie in 3.7.2 beschrieben vereiteln.
Firefox hat diese Abfrage standardmäßig aktiviert und listet im Einstellungen-Dialog, für jede gespeicherte Domain
den verwendeten Speicherplatz, bietet die Möglichkeit die Daten wieder zu löschen und Ausnahmen zu verwalten (Abbildung 3.14a).
Im Einstellungen-Dialog des Opera-Browsers kann man die Nutzung des Anwendungsspeichers generell erlauben,
verbieten, oder auf „für jede Domain fragen“ setzen (Abbildung 3.14b). Auch hier lässt sich der Speicher für jede Domain
wieder löschen.
Der Ansatz von den Chrome- und Safari-Entwicklern liegt darin begründet, dass in diesen Browsern der Anwendungsspeicher genauso behandelt wird, wie der normale Cache [3]. Insbesondere also auch mit ihm gelöscht wird, was bei
Opera und Firefox nicht der Fall ist.
(a) Firefox
(b) Opera
Abbildung 3.14: Konfiguration des Anwendungsspeichers
Cross-Domain
Das Manifest wird unter der SOP geladen und muss daher in der gleichen Domain liegen wie die Ressource. Innerhalb
des Manifestes können jedoch auch absolute URLs angegeben werden, die dann gecachet werden. Auf die Cross-Origin
Domains hat dies aber keine Auswirkungen, da die gespeicherte Version nur für das Dokument zur Verfügung steht, das
auf das Manifest verweist. Anfragen an die Cross-Domain führen also weiterhin zum Download der Ressource.
Das Manifest fügt HTML5 dadurch einen CSRF-Vektor hinzu, ähnlich einem <style> oder <img>-Tag. Im Manifest
können allerdings keine Parameter oder Fragment-Identifier übergeben werden, was die Angriffsfläche etwas einschränkt.
Angreifbar sind GET-APIs ohne Parameter und Schutz durch Tokens.
34
Tracking
Die Manifest-Datei kann zum Tracking verwendet werden; dazu muss lediglich ein Token in einer im Application
Cache gespeicherten Datei abgelegt werden. Im Manifest wird dazu die Datei tracker.js, für den Cache vorgemerkt.
Die Datei wird von dem HTML-Dokument mit dem Manifest eingebunden und hat als Inhalt var id = <token>;. Somit
ist der Benutzer per JavaScript immer über die Variable id identifizierbar, da diese bis zur Löschung im Cache bleibt.
Manifest, Cookies und LocalStorage können zwar durch den Benutzer gelöscht werden. Das passiert jedoch über drei
unterschiedliche Mechanismen. Die Webseite hat dadurch die Möglichkeit, bei Verlust einer oder zwei der drei Tokens
die gelöschten durch den oder die verbliebenen wiederherzustellen.
Die Offline Web Applications ermöglichen, was der Name besagt: Die Benutzung einer Webanwendung ohne Zugang
zum Internet. Sie könnten für Anwendungen, wie Google Docs34 interessant sein, um auch unterwegs Dokumente zu
bearbeiten und diese später mit einem Webserver zu synchronisieren. Jedoch definiert Google Docs noch keine ManifestDatei. Die geschilderten Probleme sind weniger auf das Manifest zurückzuführen als auf unsichere Verwendung von
öffentlichen Netzwerken und Implementierung anderer Webanwendungen. Interessante Ausführungen, welche Probleme
beim Erstellen einer Offline Web Application über die Sicherheit hinaus auftreten, sind unter [2] zu finden.
34
https://docs.google.com/
35
3.8 Weitere Elemente und Angriffsvektoren
Im Folgenden werden einige Neuerungen von HTML5 beschrieben, die neue Angriffsvektoren mit sich bringen. Die
Elemente bereichern HTML5-Anwendungen, gehen aber den Kompromiss mit einer größeren Angriffsfläche ein.
Die Unterstützung durch die Browser ist in Tabelle 3.9 angegeben. Die aufgelisteten Elemente werden nachfolgend
vorgestellt. Auf die Auflistung aller Event-Handler und Formular-Attribute wurde aus Übersichtsgründen verzichtet.
Browser
Chrome
Firefox
Internet Explorer
Opera
Safari
Server-Sent Events
ja
ja (CORS)
nein
ja (CORS)
ja
History API
ja
ja
nein
ja
ja
Geolocation API
ja
ja
ja
ja
ja
Sandbox
ja
nein
nein
nein
ja
Seamless
ja
nein
nein
nein
nein
Tabelle 3.9: Unterstützung der weiteren Technologien
3.8.1 Event-Handler
Mit HTML5 geht auch eine engere Verzahnung des eigentlichen HTML Dokumentes mit JavaScript einher. So kommen
einige Event-Handler für Elemente hinzu, die es Entwicklern ermöglichen, auf Ereignisse, wie das Scrollen des Sichtfensters (onscroll), das Auslösen eines Fehlers (onerror) und viele andere, zu reagieren. Vor HTML5 beschränkten sich
diese Ereignisse auf wenige mehr, als die Eingaben der Tastatur und das Verhalten der Maus.
1
2
3
4
5
<input onfocus ="alert (’’)"> 
<video >

<source onerror =" javascript :alert (’’)"></ source >
</video >
Listing 3.23: HTML5 Event-Attribute
Beim Auslösen des Events wird der im Element angegebene JavaScript Code ausgeführt. Ein Risiko für einen XSSAngriff besteht hier, wenn Benutzereingaben, die später in die Webseite eingebunden werden, nicht angemessen gefiltert
werden. Mallory wird versuchen, mit einem Formular, beispielsweise für einen Forumpost, ein Element wie in Listing 3.23
abzusenden, was anschließend in seinem Beitrag angezeigt wird. Im Beispiel wird der neue <video>-Tag dazu verwendet
JavaScript auszuführen. Gelingt es Mallory, die Zeilen 2-5 beispielsweise in einem Forum zu posten, ohne dass es gefiltert
wird, wird das JavaScript im onerror-Attribut ausgeführt, weil keine gültige Quelle angegeben ist und daher ein Fehler
erkannt wird. Genauso könnte Mallory Zeile 1 versenden. Wird auch diese Eingabe nicht korrekt gefiltert, führt auch das
zur Ausführung des Codes im onfocus-Attribut, was einem typischen XSS-Angriff entspricht. Dieses Problem existiert auch
in HTML 4, allerdings mit weniger Tags und Attributen, da mit HTML5 viele neue hinzugekommen sind.
Blacklist basierte Filter verbieten alle Tags, wie <script>, die Code ausführen könnten [26]. Diese Blacklisten müssen
aktualisiert werden, damit sie gegen das Beispiel resistent werden und nicht von den neuen Elementen und Attributen
von HTML5 umgangen werden können. Es ist ohnehin besser, in Webanwendungen Whitelists oder reguläre Ausdrücke
zu verwenden.
Eine Übersicht der Angriffsmöglichkeiten gibt Mario Heiderich mit seinem HTML5 Security Cheatsheet35 . Eine Zusammenfassung der neuen Event-Attribute wurde von w3schools.com erstellt36 .
3.8.2 Server-Sent Events
Mit den Server-Sent Events wird der letzte Weg in der Kommunikation mit HTML5 bereit gestellt, indem
ein Server unidirektional Nachrichten an den Client senden kann [53]. Dieser ruft dazu den Konstruktor new
EventSource(”event.php”) auf, der die Verbindung zur Quelle der Ereignisse herstellt. Das zurückgegebene Objekt
stellt die vom Server gesendeten Ereignisse bereit, die mit Event-Listenern abgehört werden können. Für Details und
Beispiele sei auf das Mozilla Developer Network verwiesen37 .
35
36
37
36
http://html5sec.org
http://www.w3schools.com/html5/html5_ref_eventattributes.asp
https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events
Die Server-Sent Events sind bis auf den Internet Explorer in allen Browsern implementiert. Zunächst unterlag die Kommunikation der SOP. Im Oktober 2011
wurde die Spezifikation jedoch erweitert, sodass auch die Unterstützung von
CORS-Requests erlaubt ist, was bis jetzt in Firefox und Opera implementiert ist.
Der Benutzer wird also je nach Browser durch die SOP oder die, in Abschnitt 3.5
beschriebene, CORS-API geschützt. Integrität und Vertraulichkeit können dabei
leicht durch HTTPS erreicht werden.
Der Vorteil von Server-Sent Events gegenüber WebSockets ist die einfachere
Benutzung. Es wird kein zusätzliches Protokoll benötigt, sondern auf das vertraute
HTTP gesetzt, das dazu von CORS profitieren kann.
3.8.3 History API
Aktuelle Webanwendungen laden große Teile ihrer Darstellung per AJAX38 neu,
ohne eine Veränderung an der eigentlichen Adresse der Seite vorzunehmen. Dadurch wird der Verlauf des Browsers inkonsistent zur Erfahrung des Benutzers, da
dieser mehr Zustände erlebt, als der Browser im Verlauf darstellt. Bei einem Klick auf den „Zurück“-Button wird dadurch
viel mehr Schritte zurückgesprungen, als der Benutzer eigentlich erwartet.
Deshalb wurde mit der History API dem Entwickler in HTML5 die Möglichkeit gegeben, Einfluss auf den Verlauf zu nehmen [54]. Das Verlauf-Objekt window.history stellt nun mit den beiden Methoden pushState() und replaceState()
die Möglichkeit bereit, einen Zustand zum Verlauf hinzuzufügen oder zu verändern.
Ein Angreifer kann diese API dazu benutzen, in den Verlauf eines Benutzers ohne sein Wissen URLs einzutragen, die er
niemals benutzt hat. Genauso könnte der Benutzer dazu bewegt werden, ungewollt eine Seite zu besuchen, indem sie mit
pushState() immer als letztes Element im Verlauf liegt und daher bei einem Klick auf den „Zurück“-Button aufgerufen
wird.
Die WHATWG definiert in ihrer Spezifikation auch den vom Browser auszuführenden Algorithmus beim Aufruf dieser
Methoden. Daraus ist ersichtlich, dass die History API der SOP unterliegt und daher nur Seiten in den Verlauf gelegt werden können, die innerhalb der eigenen Domain liegen [67]. Um den Benutzer trotzdem ungewollt auf beliebige Domains
weiterzuleiten, muss der Angreifer nur eine Webseite mit einer Weiterleitung auf die gewünschte Domain bereitstellen
und stattdessen diese im Verlauf ablegen.
Der Vorteil eines konsistenten Verlaufes durch die History API bringt also die Gefahr der Fälschung des Verlaufes und
der unfreiwilligen Weiterleitung mit sich, die dem Anwender bewusst werden muss, um sich nicht täuschen zu lassen.
Eine Begrenzung dieser Gefahr durch den Browser ist schwer möglich, da sich nicht feststellen lässt, ob ein Zustand einen
solchen Angriff darstellt oder nicht.
3.8.4 Associated Form
Mit dem form-Attribut für Formularelemente, wie <input> oder <textarea>, unterstützt HTML5 verschachtelte Formulare [46]. An das Attribut kann die ID eines Formulares auf der Seite übergeben werden, sodass das Element mit diesem
assoziiert wird, ohne dass es ein Nachfahre des Formulares im DOM sein muss.
Mit diesem und den Attributen zur Manipulation des Formulares formaction, formmethod, formenctype und formnovalidate [47] entsteht ein neuer XSS-Vektor in HTML5.
Die aufgeführten Attribute können in <input>-Tags mit dem Typ submit verwendet werden, um die Eigenschaften des,
möglicherweise mit dem form-Attribut, assoziierten Formulares zu verändern.
Somit genügt eine XSS-Schwachstelle, die an beliebiger Position der Seite Injektionen erlaubt, um ein Formular so zu
manipulieren, dass es beim Klick auf den eingeschleusten Button seine Informationen an den Angreifer sendet. Dazu ist
ein Beispielskript in Listing 3.24 angegeben.
Existiert auf der Seite, wie im Beispiel, ein Login-Formular und hat der Benutzer seine Daten bereits eingegeben, oder
sie wurden durch einen modernen Browser bereits automatisch eingetragen, genügt es, das Opfer dazu zu bringen, auf
das injizierte Element zu klicken und die Anmeldedaten werden an den Angreifer gesendet. Hier können natürlich auch
Technik, wie Clickjacking39 zum Einsatz kommen, um den Benutzer auf den Button klicken zu lassen.
38
39
Asynchronous JavaScript and XML
https://www.owasp.org/index.php/Clickjacking
37
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<! doctype html >
<html >
<head >
<title >Formular </title >
</head >
<body >
<form action ="./ login.php" id="f" method ="post">
<input type="text" name=" username ">
<input type=" password " name=" password ">
<input type=" submit " value =" Absenden ">
</form >

<input type=" submit " form="f" formaction ="http :// attacker .com/ steal .php">
</body >
</html >
Listing 3.24: Angriff mit dem form-Attribut
3.8.5 Geolocation API
Mit der Geolocation API stellen alle Browser eine Schnittstelle bereit, um den physischen Standort eines Gerätes festzustellen. Dabei nutzt der Browser, je nach Gerät mit entsprechender Genauigkeit, einen GPS40 -Sensor,
das Mobilfunk-Netzwerk oder berechnet den Standort anhand der IP-Adresse [40].
Alle Browser fragen den Benutzer nach seiner ZustimAbbildung 3.15: Nutzung der Geolocation API im Firefox
mung zur Übermittlung der Daten an die Webseite, wie
Firefox in Abbildung 3.15. Jedoch sind sich viele Benutzer nicht der Risiken bewusst, die sie damit eingehen. Die Geolocation API könnte dazu missbraucht werden, ein Bewegungsprofil des Nutzers zu erstellen, indem regelmäßig der Standort abgefragt wird, solange der Nutzer sich auf der
Webseite befindet. Genauso könnte man schließen, dass es sich bei Nutzern verschiedener Dienste auf unterschiedlichen
Domains um die gleiche Person handelt, wenn sie den gleichen Standort besitzen [40].
Der Nutzer muss sich dieser Möglichkeiten bewusst sein und entscheiden, wie weit er der Webseite vertraut. Bei der
Zustimmung gibt es auch die Möglichkeit, diese nur für eine Session gelten zu lassen und beim nächsten Mal wieder
gefragt zu werden. So behält man die Kontrolle über seinen Standort und kann den Zugriff nur erlauben, wenn er
wirklich erforderlich ist.
3.8.6 IFrame Sandbox und Seamless
Mit HTML5 werden für den <iframe>-Tag zwei neue Attribute eingeführt: Sandbox und Seamless [50]. Bisher werden
beide nur von Chrome unterstützt, Sandbox auch von Safari.
Enthält ein IFrame das Seamless-Attribut, wird es vom Browser nahtlos in die Umgebung integriert. Das bedeutet, dass
kein Rahmen und keine Scrollbars des IFrames dargestellt werden. Außerdem werden CSS-Deklarationen auch auf den
Inhalt des Frames angewandt; die HTML-Elemente werden als Kinder des IFrames betrachtet. Und die Verknüpfungen
der eingebetteten Seite navigieren, bei Verwendung von seamless, standardmäßig den Elternkontext. Die letzten beiden genannten Elemente der Spezifikation konnten nicht in der aktuellen Version des Chrome-Browsers nachvollzogen
werden.
Ein Seamless-IFrame erweckt beim Benutzer also den Eindruck, es handele sich um gewöhnlichen Inhalt der Seite. Ein
Angreifer kann sich diese Tatsache zu Nutze machen, indem er sich eines vorhandenen Frames bemächtigt oder eines
über eine Lücke einschleust. Das Frame unter der Kontrolle des Angreifers wird in seine Umgebung integriert, was es dem
Angreifer ermöglicht, seinem Opfer falsches Markup unterzuschieben, um es auf weitere, präparierte Seiten zu locken
oder anderweitig zu täuschen.
Das Sandbox-Attribut bestimmt, dass die eingebettete Seite in einem eigenen Kontext gestartet wird und damit von
der aufrufenden Seite getrennt wird. Es wird unter der SOP behandelt, zusätzlich werden alle Skripte und Formulare deaktiviert. Diese Einschränkungen lassen sich durch die Werte allow-forms, allow-scripts und allow-top-navigation
40
38
Global Positioning System
teilweise wieder aufheben, indem sie das Absenden von Formularen, Ausführen von Skripten und die Navigation des
Elternkontextes erlauben. Einer mit dem Sandbox-Attribut eingebetteten Seite ist auch der Zugriff auf den eigenen Web
Storage verboten, was durch den Wert allow-same-origin erlaubt werden kann.
Einige Seiten setzen Frame Busting ein, um zu verhindern, dass sie von
anderen
Seiten eingebettet werden. Besonders für sicherheitskritische Web1 if (top. location != location )
seiten,
wie
Online-Banking, ist es wichtig, nicht eingebettet zu werden, um
2
top. location = self. location ;
die Angriffsfläche für Betrüger zu verringern. Der Frame Busting Code beListing 3.25: Frame Busting [39]
sitzt immer eine Abfrage, ob sich die Seite gerade in einem Frame befindet
(Listing 3.25 Zeile 1) und einer Gegenmaßnahme (Zeile 2), die versucht den
umschließenden Kontext zu navigieren. Mit dem Sandbox-Attribut kann die
Ausführung des Frame Busting verhindert werden, sodass der Schutz der Seite wirkungslos ist und ein Angreifer sie für
seine Zwecke trotzdem einbetten kann. Als Alternative bietet sich hier der X-Frame-Options-Header an, mit dem serverseitig festgelegt werden kann, ob eine Seite eingebettet werden darf. Diese Regelung wird vom Browser ausgeführt,
sodass eine maliziöse Webseite keinen Einfluss darauf hat.
39
4 Nutzungsanalyse
Das W3C arbeitet nunmehr seit 2008 am HTML5-Standard. Einige Teile, wie die Web Workers und der Web Storage,
sind bereits in den Status einer „Candidate Recommendation“ fortgeschritten. Es ist also unwahrscheinlich, dass sich
elementare Teile der Spezifikation ändern. Um die aktuelle Nutzung nach vier Jahren Entwicklung festzustellen, wurde
im Rahmen dieser Arbeit ein Crawler geschrieben, der die Verbreitung von neuen Elementen in HTML analysiert.
4.1 Aufbau
Der Crawler soll möglichst schnell eine Liste von Domains abarbeiten, die Seiten herunterladen, abspeichern und auf
HTML5 untersuchen. Dazu wurde er in zwei Komponenten aufgeteilt, den Downloader und den Scanner. Die Aufgabe
des Downloaders ist es, die angegebenen Seiten herunterzuladen und im Dateisystem abzulegen. Der Scanner nimmt
die abgelegten Seiten und sucht nach Schlüsselwörtern für HTML5-Elemente. Diese Trennung hat den Vorteil, dass der
Scanvorgang wiederholt werden kann, ohne die Webseiten zeitaufwändig erneut herunterladen zu müssen.
4.1.1 Downloader
Der Downloader erhält als Eingabe die 10.000 meistbesuchten Seiten nach dem Alexa-Ranking [1] vom 12. August 2012.
Für jede Domain wird die jeweilige Homepage heruntergeladen und abgespeichert, sowie die mit ihr ausgelieferten
HTTP-Header. Die Homepage wird nach, mittels <script src=”?”> eingebundenen, JavaScript-Dateien durchsucht, die
ebenfalls heruntergeladen werden.
Ein CORS-Header wird möglicherweise nur bei einem passenden Origin-Header gesendet. Daher wurde, wie in [25],
für jede Domain sie selbst als Wert des Origin-Headers der Anfrage hinzugefügt, um die Header herunterzuladen.
Weiterhin ist bekannt, dass einige Webseiten, wie beispielsweise Wikipedia, spezielle Crawlerseiten ausliefern, die
nicht den eigentlichen Inhalt der Seite darstellen. Daher gibt sich der Crawler durch den Header in Listing 4.1 als Firefox
Browser auf einem Windows 7 PC aus.
1
User -Agent: Mozilla /5.0 ( Windows NT 6.1; rv :12.0) Gecko /20120403211507 Firefox /14.0.1
Listing 4.1: User-Agent Header des Crawlers
Der Crawl wurde zwischen dem 14. und 24. August 2012 durchgeführt. Es konnten die Daten von 9731 Domains mit
einem Volumen von 2,8 GB heruntergeladen werden. 269 Domains waren nicht erreichbar.
4.1.2 Scanner
Der Scanner nimmt die heruntergeladenen Domains als Eingabe und prüft, ob die HTML5-Elemente verwendet werden.
Nach den Elementen muss dabei mit den folgenden fünf verschiedenen Arten gesucht werden:
1. Die heruntergeladenen Header werden auf den Access-Control-Allow-Origin und X-Frame-Options-Header
geprüft.
2. Es wird über die Tags der Homepage iteriert und verglichen, ob es sich um den Gesuchten handelt.
3. Für Attribute werden die in Frage kommenden Tags der Homepage gefiltert und auf das Attribut hin geprüft.
4. Um Elemente in JavaScripts zu finden, wie Konstruktoren der Worker oder Zugriffe auf den Web Storage, werden die heruntergeladenen Skripte durchsucht, ebenso wie der gesammte in einem <script>-Tag der Homepage
notierte Code.
5. Event-Handler können sowohl als Attribut, als auch per JavaScript definiert werden. Die heruntergeladene Seite
und die Skripte werden auf die Definition der Handler untersucht.
Wird eine Eigenschaft festgestellt, wird dies in einer CSV-Datei vermerkt, die nach Abschluss des Scan-Vorganges zur
Analyse der Seiten dient. Die Ergebnisse der Analyse werden im folgenden Kapitel vorgestellt.
40
4.2 Ergebnis
Für die Nutzung von HTML5 können zwei Merkmale herangezogen werden:
1. Die Verwendung einer der hier vorgestellten APIs, die die Verwendung von 2. nicht erzwingen.
2. Die Angabe des Doctypes, der den Typ des folgenden Markups bestimmt. Für HTML5 ist <!DOCTYPE html> vorgesehen.
Für den ersten Indikator wurden von den 9731 untersuchten Domains 3279, das sind 34 %, erkannt, die eine der
betrachteten Funktionen von HTML5 verwenden.
Die Angabe des Doctypes erlaubt die Verwendung von neuen Elementen, die hauptsächlich der Strukturierung des
Inhaltes dienen und keinen Einfluss auf die Sicherheit von HTML5 besitzen. Für das zweite Merkmal wurden 2170
Dokumente (22 %) erkannt, die mit dem Doctype ausgeliefert werden.
Allerdings gibt dieser Doctype nur über das HTML-Markup Auskunft. Die Verwendung der neuen JavaScript-APIs ist
auch ohne ihn möglich und nur von der verwendeten Browserversion abhängig. So benutzen 1096 Domains (11 %) mit
Doctype gar keine der hier betrachteten Features.
Umgekehrt verwenden 2205 Domains (23 %) mindestens eines der analysierten Elemente, ohne mit dem HTML5Doctype ausgeliefert zu werden. Nur ein Drittel (1074) der Seiten, die eines der Elemente verwenden, wird auch mit
dem Doctype ausgeliefert. Zählt man die untersuchten JavaScript APIs und den Doctype zusammen, benutzen 4375
Domains (45 %) bereits HTML5.
Das Diagramm in Abbildung 4.1 zeigt den Anteil der Domains, die HTML5 benutzen, bis zum entsprechenden Rang.
Dabei wurde als Kriterium entweder der Doctype (Doctype) oder die Nutzung eines der vorgestellten Elemente (HTML5)
herangezogen. Kombiniert entspricht der Oder-Verknüpfung beider Merkmale – wie oben beschrieben. Man erkennt, dass
sich in den TOP 1.000 mehr Domains befinden, die HTML5 verwenden und sich der Anteil dann mit höherem Rang
schnell bei ca. 45 % einpendelt. Interessant ist außerdem, dass außerhalb der TOP 1.000 deutlich mehr Webseiten eine
der JavaScript APIs verwenden, ohne auch ihr HTML-Markup selbst auf HTML5 umzustellen (Differenz zwischen HTML5
und Doctype). Dabei würde es in den meisten Fällen genügen, den Doctype auszutauschen, da viele Elemente aus HTML
4.01 übernommen wurden und daher kompatibel sind.
Im Folgenden werden die Ergebnisse zu den einzelnen Elementen vorgestellt, abschließend werden in Tabelle 4.1 die
Ergebnisse übersichtlich zusammengefasst.
Abbildung 4.1: Anteil Nutzung HTML5 nach Rang
41
Associated Form
Trotz der zusätzlichen gestalterischen Möglichkeiten, die das form-Attribut, durch die Entzerrung der Formulare über
eine Seite hinweg, bietet, konnte keine Domain gefunden werden, die es benutzt. Deshalb ist auch die Suche nach den
Attributen formaction und formmethod, etc. (siehe Abschnitt 3.8.4) obsolet, da sie ohne das form-Attribut keine Funktion
besitzen.
CORS
Die Suche nach dem CORS-Header Access-Control-Allow-Origin ergab 63 Treffer, darunter waren nur 13 mit einem
gesetzten Wert, wie etwa mtv.com, dessen Startseite (immer) mit dem Wert „http://c.brightcove.com“ ausgeliefert wird.
Die anderen 50, also etwa 80 %, verfolgend mit der Wildcard eine potentiell unsichere CORS-Strategie. So auch die
drei ranghöchsten Domains mit CORS, die auf den Plätzen 168, 258 und 327 in den TOP 1.000 liegen. Erst außerhalb der
TOP 1.000 wurden die ersten Domains ohne Wildcard gefunden, trotzdem bewegt sich der Anteil der Wildcard-Regeln
auch bei hohem Rang zwischen 70 und 80 %, wie in Abbildung 4.4 dargestellt. Allerdings geht von der Wildcard keine
unmittelbare Gefahr aus, wenn die Seite ohne Zugangsbeschränkung sowieso erreichbar ist. Probleme durch die Wildcard
treten besonders dann auf, wenn Sitzungs-Authentifizierte Seiten durch CORS erreichbar sind [48].
Im Jahr 2011 wurden von S. Lekies 215 Domains unter den Alexa TOP 1.000.000 mit einem CORS-Header festgestellt [25]. Das entspricht etwa 0,02 %, während die hier gefundenen Domains einem Anteil von 0,06 % entsprechen.
Dies bestätigt den von Lekies gefundenen Trend, dass mit höherem Rang auch eine größere Wahrscheinlichkeit für CrossDomain Anfragen besteht, da der unter den TOP 10.000 gefundene Anteil dem Dreifachen des unter den TOP 1.000.000
gefundenen entspricht. Lekies fand weiterhin heraus, dass das Vorbild für CORS Adobe Flash unabhängig vom Rang
zu etwa 1,5 % in unsicherer Weise verwendet wird. Dieser Zusammenhang kann auch für die CORS Wildcard hergestellt werden, die unabhängig vom Rang von etwa 0,5 % aller Webseiten verwendet wird (siehe Abbildung 4.4 CORS
#Wildcard/Rang).
EventSource
Es wurden fünf Domains gefunden, die eine EventSource verwenden. Auf justdial.com wird sie dazu verwendet, Bewertungen von anderen Benutzern live auf der Startseite einzublenden, ohne die Seite selbst neu laden zu müssen und
ohne selbst ständig beim Server nach Updates zu fragen. Das entspricht der Intention der EventSource, mit der sie in die
Spezifikation aufgenommen wurde.
Geolocation API
Die Geolocation API wird von 62 Domains (1 %) verwendet. Ein Beispiel hierfür ist ca.gov, die Webseite des US
Bundesstaates Kalifornien. Hier kann man seine Position über die Geolocation API bestimmen lassen, um regionale Ergebnisse für Suchanfragen zu erhalten. Für Browser ohne die API hält ca.gov auch eine Lokalisierung über die Postleitzahl
bereit, die unter Umständen präziser sein kann, wenn das Gerät keinen GPS-Sensor besitzt und die Position anhand der
IP-Adresse bestimmt wird.
History API
Auf myspace.com wird die History API, ebenso wie auf insgesamt 278 Webseiten (3 %) verwendet. Wie vom Standard
vorgesehen speichert Myspace einen Zustand im Verlauf des Browsers, wenn durch eine Aktion des Benutzers nicht die
komplette Seite, sondern nur ein Teil, neu geladen wurde. Für ältere Browser ist auf Myspace auch noch die alte Variante
vorhanden, bei der der Zustand von dynamisch nachgeladenen Teilen über den Fragment-Identifier (oder Hash) der URL
repräsentiert wurde. Um dieser Zweckentfremdung einen Standard zu geben, wurde die History API eingeführt.
Keygen
Der <keygen>-Tag wird auf keiner der Top 10.000 Domains verwendet. Dies war auch zu erwarten, da in Anwendungsfällen vor dem Generieren eines Schlüssels zunächst andere Prozesse ablaufen müssen. So zum Beispiel die Abfrage von
Benutzerinformationen oder ein Anmeldevorgang. Es ist daher sehr unwahrscheinlich, dass die Generierung direkt auf
der Startseite geschieht.
Ein <keygen> Element ist vermutlich eher in tieferen Ebenen einer Domain zu finden. So wie bei Startcom1 , wo
zunächst ein Benutzerkonto mit persönlichen Daten erstellt werden muss, bevor ein Schlüssel generiert wird, der später
zur Authentifizierung verwendet werden kann. Dieses Szenario wird nicht vom Crawler abgedeckt.
Offline Web Applications
Entgegen der Erwartung konnte keine Domain gefunden werden, die ein Manifest verwendet. Wahrscheinlich ist die
Startseite einer Domain ein zu dynamischer Bereich, als dass man diesen Code für längere Zeit zwischenspeichern kann.
1
42
http://www.startssl.com/
Möglich wäre auch, dass das Manifest nur an mobile Browser ausgeliefert wird, um eine schnellere Verbindung bei
geringerem Übertragungsvolumen zu erreichen und daher vom Crawler nicht erfasst wurde.
Sandbox und Seamless
Nur vier der 10.000 Webseiten verwenden das Seamless-Attribut, mit dem ein
IFrame ohne Rahmen in die umschließende Seite integriert wird. Das liegt zum
einen daran, dass es bisher nur vom Chrome-Browser unterstützt wird und Entwickler sich daher noch nicht auf die Funktionalität verlassen können. Zum anderen ist die nahtlose Integration ohne optische Trennung auch leicht mit einigen
CSS-Eigenschaften zu erstellen, die ohnehin für die anderen Browser benötigt
werden und daher schon vorhanden sind. Ein Beispiel für die Verwendung des
Seamless-Attributes findet sich auf stylebook.de. Hier wird ein so genannter „Ge- Abbildung 4.2: „Gefällt Mir“-Button
fällt Mir“-Button in die Seite integriert, mit dem Benutzer des sozialen Netzwerks
auf stylebook.de
Facebook2 ihre Vorliebe für die Webseite ausdrücken können. Für einen normalen
Benutzer des Internets ist nicht zu erkennen, dass es sich nicht um Inhalt von Stylebook.de handelt (siehe Abbildung 4.2). Ein Angreifer hat damit die in Abschnitt 3.8.6 vorgestellten Möglichkeiten sein
Opfer zu täuschen, da – wie zu sehen – keine optische Trennung stattfindet.
Überraschenderweise wird das Sandbox-Attribut von keiner einzigen Domain verwendet, obwohl insgesamt 3586 Domains (37 %) mit einem IFrame gefunden wurden. Dabei kann es als unkritisch betrachtet werden, wenn der Inhalt des
IFrames von der gleichen Domain stammt, denn seinem eigenen Inhalt sollte man vertrauen können. Allerdings sind
unter den 3586 Seiten mit IFrames auch 2406, die eine Seite von einem fremden Origin einbetten. Das entspricht 25 %
aller untersuchten Seiten und 67 % der Seiten mit einem IFrame.
Daher wird aber auch von den Alexa TOP 10.000 Webseiten keine Seite gegen ihren Willen eingebettet, indem durch
das Sandbox Attribut der Frame Busting Code an der Ausführung gehindert wird. Die von Rydstedt vorgestellten Möglichkeiten der Implementierung von Frame Busting [39] konnten bei 219 (2 %) der Domains festgestellt werden. Weitere
264 verwenden den X-Frame-Options-Header [31]. Obwohl beide, der JavaScript Code und der Header, das gleiche Ziel
haben, nämlich das Einbetten zu verhindern, wurden sechs Domains gefunden, die beide Abwehrtechniken einsetzen,
was redundant ist.
Web Messaging
Es wurden 1966 Domains (20 %) gefunden, die die Web Messaging Schnittstelle benutzen. Sie kann zur Kommunikation mit Frames anderer Domains oder mit den Web Workern benutzt werden. Da nur sieben Web Worker gefunden
wurden, entfällt der größte Anteil auf die Kommunikation mit anderen Frames.
Von 1966 Domains nutzen 1559 (79 %, TOP 10.000: 16 %) die postMessage-Methode und 1842 (94 %, TOP 10.000:
19 %) den onMessage-Event-Handler. Darunter sind 1435, die beide Schnittstellen verwenden; sie können bidirektional
kommunizieren, während 124 nur Nachrichten senden und 407 nur Nachrichten empfangen können.
Weiterhin wurden 923 Domains identifiziert, die beim Aufruf von postMessage() die unsichere Wildcard benutzen.
Das entspricht einem Anteil von 9 % an allen untersuchten Domains und 60 % an den Webseiten, die die postMessageMethode verwenden.
In Abbildung 4.4 ist der Anteil der Domains dargestellt, die bis zum entsprechenden Rang die postMessage-Methode
unsicher verwenden. Das kann dazu führen, dass – möglicherweise sensible – Daten an einen Angreifer übertragen
werden, der sich als empfangendes Frame eingeschlichen hat. Innerhalb der TOP 1.000 besteht eine deutlich geringere
Wahrscheinlichkeit für die unsichere Verwendung von Web Messaging. Außerhalb der TOP 2.000 verwendet mehr als die
Hälfte der Domains die Wildcard, wenn sie Web Messaging einsetzen.
WebSocket
Zehn Domains verwenden das WebSocket Protokoll, wie zum Beispiel Stackexchange.com. Stackexchange ist ein Netzwerk von Webseiten, auf denen Amateure und Profis Fragen zu bestimmten, technischen Themen stellen können, die von
anderen Benutzern beantwortet und bewertet werden. Am bekanntesten ist Stackoverflow, wo Fragen rund ums Programmieren gestellt werden.
Stackexchange nutzt die WebSocket API, um ständig die neuesten, auf einer Seite des Netzwerkes gestellten Fragen
auf seiner Startseite zu präsentieren.
Web Storage
Von den 9731 untersuchten Domains benutzen insgesamt 1565 (16 %) den Web Storage. Davon konnten 1465 (15 %)
Webseiten identifiziert werden, die den LocalStorage benutzen, der – ähnlich wie die Cookies – über mehrere Sitzungen
2
http://facebook.com
43
persistent bleibt. Der SessionStorage, der nach dem Schließen des Fensters gelöscht wird, wird von 623 (6 %) der
untersuchten Webseiten verwendet. Beide Speicher gleichzeitig werden von 523 Domains genutzt.
Zwei Domains nutzen das Storage-Event, darunter badoo.com, wo das Ereignis
ausgenutzt wird, um zwischen allen geöffneten Fenstern der Domain zu kommunizieren (siehe Abschnitt 3.4.1).
Das von Microsoft eingeführte Storagecommit-Event konnte nicht gefunden
werden. Das legt zwei Gründe nahe: Zum einen wird es nur vom Internet Explorer unterstützt und ist nicht im Standard; und zum anderen lässt sich kein
Anwendungsfall finden, bei dem der Unterschied zwischen dem Ablegen des Wertes im Speicher und auf der Festplatte relevant wäre.
Nathan Goods konnte in einer Studie über Web Tracker vom Juni 2012 unter den TOP 100 von Quantcast3 34 Domains mit LocalStorage identifizieren, in
dieser Untersuchung konnten 37 gefunden werden [32]. In den TOP 1.000 fand
Goods 253, während es hier nur 241 sind. Goods untersuchte die TOP 25.000,
Abbildung 4.3: Anteile Web Storage unter denen er bei etwa 10 % Domains mit LocalStorage finden konnte. Dem stehen 15 % der TOP 10.000 aus dieser Studie gegenüber. Insgesamt lässt sich also
ein ähnlicher Trend, wie bei der Nutzung von HTML5 überhaupt, feststellen: Mit
höherem Rang steigt auch die Wahrscheinlichkeit für den Einsatz von LocalStorage.
Web Worker
Insgesamt wurden sieben Web Worker gefunden. Auf Virustotal.com wird der Worker dazu verwendet, die SHA-256
Prüfsumme einer Datei zu berechnen. Das ist ein sehr gutes Beispiel für den Anwendungsfall von Workern, denn JavaScript ist nicht für seine Geschwindigkeit bekannt. Eine gute JavaScript Implementierung berechnet in einer Sekunde die
Prüfsumme von 40 - 150 kB Daten [41], abhängig vom verwendeten Browser. Bei 100 kB/s bedeutet das, dass eine nur
1 MB große Datei jegliche Skript-Reaktion der grafischen Oberfläche für 10 Sekunden blockieren würde.
Für diesen Zweck wurden die Worker eingeführt. Der im Beispiel beschriebene Worker erhält eine Datei, berechnet
ihre Prüfsumme und informiert, durch die Web Messaging Schnittstelle, die grafische Oberfläche über das Ergebnis. Diese
konnte in der Zwischenzeit auf Eingaben des Benutzers reagieren, während der Worker im Hintergrund die Berechnungen
durchführte.
Abbildung 4.4: Unsichere Nutzung von CORS und Web Messaging
3
44
http://www.quantcast.com/
Element
Vorkommen
HTML5
Doctype HTML5
kombiniert
Associated Form
CORS
EventSource
Geolocation API
History API
Keygen
Manifest
Web Messaging
3279
2170
4375
0
63
5
62
278
0
0
1559
34 %
22 %
45 %
inkl. onMessage
Wildcard
1966
923
20 %
9%
WebSocket API
Web Storage
10
1565
16 %
LocalStorage
SessionStorage
beide
1465
623
523
15 %
6%
5%
Web Worker
IFrame
Cross-Domain
Sandbox
Seamless
Frame Busting
X-Frame-Options
onMessage
onStorage
onStorageCommit
7
3586
2406
0
4
219
270
1842
2
0
1%
1%
3%
16 %
37 %
25 %
2%
3%
19 %
Beispiel
http://www.sourceforge.net/
http://justdial.com/
http://www.ca.gov/
http://www.myspace.com/
http://www.mediafire.com/
http://www.stumbleupon.com/
http://stackexchange.com/
http://google.com
http://facebook.com
http://www.amazon.com/
https://www.virustotal.com/
http://yahoo.com
http://www.stylebook.de/
http://www.stylebook.de/
http://live.com/
https://www.facebook.com/
http://www.ebay.com/
http://badoo.com/
Tabelle 4.1: Vorkommen der HTML5 Elemente
5 Fazit
HTML5 ist die Antwort auf den Technologie-Bedarf von modernen, dynamischen Webanwendungen. Es führt viele neue
Möglichkeiten ein, die die Einschränkungen in der Entwicklung aufheben. Allerdings gibt es, obwohl bei der Definition
des Standards viel Wert auf Sicherheit und Datenschutz gelegt wurde, noch einige Fallstricke, die beim Erstellen einer
Applikation beachtet werden müssen.
Ein großes Problem ist, dass HTML5 eine größere Oberfläche für XSS-Angriff bietet, statt sie zu verkleinern. Eine
Lücke kann nun zusätzlich zur Kompromitierung des Web Storage führen und ein Angreifer kann mit WebSockets, CORS
und den Web Workern unbemerkt sein Unwesen treiben und Schaden anrichten. Das Problem ist, dass all diese Angriffe
ablaufen können, ohne das der Benutzer sie bemerkt, weil sie im Hintergrund laufen. Natürlich ist es Aufgabe der
Programmierer, sichere Anwendungen zu schreiben, aber XSS ist kein Problem von HTML an sich, sondern vielmehr
von mangelhafter Validierung und Filterung von Benutzereingaben. Man kann daher HTML5 nicht die Schuld für diese
Angriffe geben, da die Ursachen an anderer Stelle bekämpft werden müssen. Richtig ist, dass HTML5 die Auswirkungen
eines XSS-Angriffes vergrößert, da es dem Angreifer viele neue Möglichkeiten gibt. Aber diese Möglichkeiten sind gerade
das, was moderne Applikationen verlangen und daher mit HTML5 neu geschaffen wurde.
HTML5 vereinfacht zwar die Arbeit der Entwickler, verschiebt jedoch die Risiken auf den Benutzer des Webs, der die
Kontrolle über seine Daten weiter abgibt. Die Positionsbestimmung durch die Geolocation API, die erweiterten Möglichkeiten des Trackings durch den LocalStorage und die Offline Web Applications geben weiter kleine Stücke der
Privatsphäre preis. Für den normalen Benutzer des Webs ist es vielleicht noch erkennbar, wer gerade seine Position
bestimmt, aber er weiß nicht, ob diese Information gerade durch eine CORS Anfrage an einen Server weitergeleitet wird,
dem er seine Position eigentlich nicht anvertrauen wollte.
HTML, JavaScript und CSS sind Sprachen, mit denen man eine Anwendung einmal schreibt und dann (fast) überall
ausführen kann. Unabhängig vom Betriebssystem und den Vorlieben des Benutzers für einen bestimmten Browser. Die
drei Sprachen werden mittlerweile sogar in Umgebungen jenseits eines Browsers eingesetzt, um Anwendungen zu schreiben. So wird beispielsweise in Apples iTunes, der iTunes Store als Webseite heruntergeladen und von WebKit, das auch in
Safari und Chrome verwendet wird, dargestellt. Das hat für die Programmierer den Vorteil, dass bei Änderungen im Store
kein Update des Programmes notwendig ist, da der Inhalt ohnehin aus dem Internet heruntergeladen wird. Ganz davon
abgesehen ist es mit HTML viel einfacher grafische Oberflächen zu erstellen. Dieser „Write Once, Run Everywhere“ Vorteil
ist gleichzeitig auch der Nachteil, denn er gilt auch für Angreifer: „Finde eine Lücke und nutze sie überall aus.“ Daher
ist zu erwarten, dass die Angriffe auf Webanwendungen in Zukunft weiter zunehmen, denn die Verbreitung von HTML
steigt und die Zahl der weltweiten Internetnutzer ebenfalls. Je mehr die Technologie verwendet wird, desto attraktiver
erscheint sie für Angreifer.
Mit HTML5 nimmt auch die Verantwortung des Browsers weiter zu. Er ist die Verteidigungslinie auf der Client-Seite,
der immer mehr Aufgaben übernimmt, die die Sicherheit betreffen. So zum Beispiel die Kontrolle über CORS-Anfragen,
aber auch die Verantwortlichkeit für die Validierung von Informationen nimmt damit zu. Antworten von fremden Domains
auf XHRs, WebSockets oder Server-Sent Events, aber auch der Inhalt des Web Storage können nicht, wie bei XSS-Filtern,
serverseitig kontrolliert werden. Diese Aufgabe muss vom Browser übernommen werden, umso wichtiger ist es ihn durch
Updates immer auf dem aktuellsten Stand zu halten.
Fast die Hälfte der Webseiten setzt schon auf HTML5, obwohl der Standard längst nicht fertig ist. Bei einigen Elementen, besonders bei CORS und Web Messaging, muss aber bei den Entwicklern noch das Bewusstsein für die Sicherheit und
den Datenschutz geschaffen werden, damit die Anzahl der unsicheren Implementierungen weiter absinkt. Aber auch der
Benutzer des Webs muss sich mit offenen Augen durch das Internet bewegen, um mit der richtigen Konfiguration seines
Browsers und der JavaScript-APIs seine Informationen zu schützen. Diese Aufgabe kann ihm im modernen Internet kein
Browser abnehmen.
Bei einigen Features sind die Entwickler noch sehr zurückhaltend. So könnte durch das <keygen>-Element und die
Kryptographie-API, das Problem von mehrfach verwendeten oder unsicheren Passwörtern gelöst werden. Die Offline Web
Applications können den Trend zur Cloud mit Software-As-A-Service unterstützen, indem sie die Anwendungen auch
ohne Internetzugang nutzbar machen.
Andere Features, wie der Web Storage und das Web Messaging, werden schon von vielen Entwicklern benutzt. Das
bestätigt ihre Notwendigkeit und fördert die Entwicklung moderner Webanwendungen.
46
5.1 Verwandte Arbeiten
Viele Wissenschaftler und Entwickler befassen sich mit HTML5 und der Sicherheit im World Wide Web.
• Caniuse.com listet ausführlich auf, welche Browser in welcher Version ein bestimmtes Element unterstützt. Das
nicht nur für HTML5, sondern auch auch für JavaScript und CSS. Detailiert kann hier auch die Unterstützung in
kommenden Browserversionen eingesehen werden.
• Mario Heiderich listet auf heideri.ch/jso/ eine Vielzahl von Angriffsvektoren auf, die auch über HTML5 hinaus
gehen. Die ausführliche Liste kann zum Erstellen neuer XSS-Filter verwendet werden, die auch HTML5-sicher
sind.
• Auf andlabs.org werden einige Proof-Of-Concept Implementierungen vorgestellt, die die Angriffsmöglichkeiten mit
HTML5 demonstrieren. Allerdings haben sich die Autoren anderen Projekten zugewendet, sodass die aktuellsten
Entwicklungen noch keinen Einfluss nehmen konnten.
• Viele Autoren beschäftigen sich mit der Sicherheit von HTML5. Neben den bereits genannten ist das Shreeraj Shah,
der seine Erkenntnisse in seinem Blog auf shreeraj.blogspot.de veröffentlicht, wie seine „Top 10 HTML5 Threats &
Attack Vectors“.
• Auf html5security.org werden zahlreiche Arbeiten zum Thema gesammelt.
• Ähnliche Analysen der Sicherheit wurden von Michael Schmidt [40], Philippe De Ryck [10] und Robert McArdle [26] erstellt. Ihr Fokus liegt auf anderen Elementen, die zum Teil noch kaum implementiert sind oder sie
befassen sich nicht so detailiert mit der Materie. Eine umfangreiche Studie zur Nutzung existierte vor dieser Arbeit
noch nicht.
Zu erwähnen sind auch die Mailinglisten und besonders der offizielle IRC Channel der WHATWG, in dem man direkten
Kontakt zu den Autoren des Standards herstellen kann und schnell gute Antworten auf Fragen bekommt.
5.2 Ausblick
HTML5 ist bereits weit vorangeschritten: Drei der Spezifikationen sind bereits eine „Candidate Recommendation“ und
daher schon stabil. Das sind die Web Worker, der Web Storage und das Web Messaging. Auch in den Browsern ist es weit
verbreitet. Der Stand wird von html5test.com gemessen und kann dort auch mit älteren Browserversionen verglichen
werden.
Weiterführend könnte untersucht werden, welchen Einfluss die unterschiedlichen Implementierungsstände der Browser haben. Dazu könnte der Crawl mit anderen Headern, als dem in Listing 4.1 angegebenen, durchgeführt werden. Der
Crawler sollte sich damit als Chrome, Opera, Safari oder Internet Explorer Browser ausgeben. Dann könnte betrachtet
werden, ob an Browser, die weniger Elemente von HTML5 unterstützen, auch weniger HTML5 ausgeliefert wird. Oder
die Seiten unterscheiden sich nicht, da eine Unterscheidung der Browser auf Clientseite leichter zu realisieren ist.
Der Crawler analysiert den heruntergeladenen JavaScript-Code statisch. Weitergehend könnte ein Parser eingesetzt
werden, der eine dynamische Analyse durchführt, um (1) dynamisch nachgeladene Skripte zu finden und ebenfalls zu
untersuchen, (2) zu analysieren, ob im onmessage-Handler Prüfungen stattfinden, um die Absender einer Nachricht zu
unterscheiden (wie in Listing 3.4) und (3) wird nur betrachtet, welche Domains einen CORS-Request erlauben. Man
könnte daher umgekehrt untersuchen, welche Skripte einen CORS-Request durchführen, indem man feststellt, an welche URLs ein AJAX-Request gesendet wird. Eine dynamische Analyse ist erforderlich, da alle drei Aufrufe meist durch
Variablen parametrisiert sind und daher nur zur Laufzeit bestimmt werden können.
Nach acht Jahren Entwicklungszeit und noch weiteren vier Jahren bis zur Festlegung des Standards vom W3C in
2016, wird HTML5 bereits von 45 % der Webseiten benutzt und der Anteil wird sicherlich weiter ansteigen. Bis 2016
wird viel Feedback von Entwicklern einfließen und auch einige neue Teile hinzukommen, wie die kürzlich veröffentlichte Kryptographie-API. Allerdings ist die Position des Editors beim W3C weiterhin vakant, nachdem Ian Hickson sich
ausschließlich auf den „Living Standard“ der WHATWG konzentrieren wird. Daher ist es von nun an wichtig, darauf zu
achten, dass sich die Spezifikationen durch mehrere Autoren nicht voneinander entfernen. Denn seit Beginn der Arbeiten
ist klar, dass das Web keine zwei HTML Standards braucht, denn bereits 1994 hat Tim Berners-Lee (erfolgreich) versucht
eine Spaltung des Internets zu verhindern. Wenn diese Hürde überwunden ist, können HTML5 und der „Living Standard“
weiter auf das Ziel eines interoperablen Standards hin arbeiten, sodass Webanwendungen ohne Tricks in allen Browsern
funktionieren. Es bleibt genug Zeit, Sicherheitslücken zu identifizieren und ihnen entgegen zu wirken, damit HTML5
auch trotz der vielfältigen neuen Kommunikationswege und APIs sicher bleibt.
47
Abkürzungsverzeichnis
AJAX
Asynchronous JavaScript and XML 37, 47
API
Application Programming Interface 4, 19, 30, 31, 34, 37, 38, 41–43, 45–47
CORS
Cross-Origin Resource Sharing 5, 8, 26–29, 37, 40, 42, 45–47
CSP
Content Security Policy http://www.w3.org/TR/CSP/ 12
CSRF
Cross-Site Request Forgery [35] 5, 28, 34
CSS
Cascading Style Sheets 4, 38, 43, 46, 47
DOM
Document Object Model 4, 5, 17, 21, 25, 37
DSA
Digital Signature Algorithm 18
EC
Elliptic Curves 18
GPS
Global Positioning System 38, 42
HTML
Hypertext Markup Language 1, 4, 6–8, 14, 15, 20, 24, 32, 35, 36, 38, 40, 41, 46, 47
HTML Version 5 1, 2, 4–9, 13–15, 18, 20, 22, 24, 26, 28, 29, 31, 34, 36–38, 40, 41, 44–47
HTTP
HyperText Transfer Protocol 5, 8, 26–31, 33, 37, 40
HTTPS
HyperText Transfer Protocol Secure 5, 19, 28, 29, 33, 37
JSON
JavaScript Object Notation http://json.org 9, 10
PKI
Public Key Infrastructure [12] 19
RSA
Kryptographisches Verfahren nach Rivest, Shamir und Adleman [37] 18
SOP
Same-Origin-Policy [38] 4, 5, 8, 9, 11–13, 16, 17, 22, 25, 26, 29, 31, 33, 34, 37, 38
SPKAC
SignedPublicKeyAndChallenge 18, 19
49
SSL
Secure Socket Layer 30
TCP
Transmission Control Protocol 29
TLD
Top Level Domain 21
URL
Unified Ressource Locator 9, 16, 22, 29, 32, 34, 37, 42, 47
W3C
World Wide Web Consortium [64] 6, 7, 14, 19, 20, 23, 26, 29, 40, 47
WHATWG
Web Hypertext Application Technology Working Group [68] 6, 7, 14, 20, 37, 47
WLAN
Wireless Local Area Network 33
XHR
XMLHttpRequest 2, 5, 8, 12, 26, 28, 30, 46
XSS
Cross-Site Scripting 16, 22, 24, 25, 28, 36, 37, 46, 47
50
Literaturverzeichnis
[1]
ALEXA: Top Sites. http://www.alexa.com/topsites, August 2012
[2]
ARCHIBALD, Jake:
Application Cache is a
application-cache-is-a-douchebag/, Mai 2012
[3]
ATTACK & DEFENSE LABS: Chrome and Safari users open to stealth HTML5 AppCache attack. http://blog.andlabs.
org/2010/06/chrome-and-safari-users-open-to-stealth.html, Juni 2010
[4]
ATTACK & DEFENSE LABS: Shell of the Future – Reverse Web Shell Handler for XSS Exploitation. http://blog.andlabs.
org/2010/07/shell-of-future-reverse-web-shell.html, Juli 2010
[5]
ATTACK & DEFENSE LABS: What is Ravan? http://www.andlabs.org/tools/ravan/ravan.html, Dezember 2010
[6]
BARTH, A. ; CABALLERO, J. ; SONG, D.: Secure content sniffing for web browsers, or how to stop papers from reviewing
themselves. In: Security and Privacy, 2009 30th IEEE Symposium on IEEE, 2009, S. 360–371
[7]
BARTH, Adam: Experiment comparing Upgrade and CONNECT handshakes. http://www.ietf.org/mail-archive/
web/hybi/current/msg04744.html, November 2010
[8]
BUNDESVERBAND DES DEUTSCHEN VERSANDHANDELS: Aktuelle Zahlen zum Interaktiven Handel. http://www.bvh.info/
zahlen-und-fakten/allgemeines/, 2011
[9]
BUNDESVERBAND DEUTSCHER BANKEN: Fakten und Zahlen aus der Kreditwirtschaft. https://www.bankenverband.de/
publikationen/ods/die-privaten-banken-fakten-und-zahlen, September 2011
Douchebag.
http://www.alistapart.com/articles/
[10] DE RYCK, P. ; DECAT, M. ; DESMET, L. ; PIESSENS, F. ; JOOSEN, W.: Security of web mashups: a survey. In: 15th Nordic
Conference in Secure IT Systems (NordSec 2010), 2011
[11] FELTEN, E.W. ; BALFANZ, D. ; DEAN, D. ; WALLACH, D.S.: Web spoofing: An internet con game. In: Software World 28
(1997), Nr. 2, S. 6–8
[12] FORCE, Internet Engineering T.: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile. http://tools.ietf.org/html/rfc5280, Mai 2008
[13] FORCE, Internet Engineering T.: The WebSocket Protocol. http://tools.ietf.org/html/rfc6455, Dezember 2011
[14] GAMMA, Erich ; HELM, Richard ; JOHNSON, Ralph ; VLISSIDES, John: Design patterns: elements of reusable object-oriented
software. Addison-Wesley Professional, 1995
[15] GONZÁLEZ, Scott: Web Storage Support Test. http://dev-test.nemikor.com/web-storage/support-test/, Mai
2012
[16] GROSSMAN, J.: Whitehat website security statistics report. In: WhiteHat Security (2012)
[17] GULLI, A. ; SIGNORINI, A.: The indexable web is more than 11.5 billion pages. In: Special interest tracks and posters
of the 14th international conference on World Wide Web ACM, 2005, S. 902–903
[18] HANNA, S. ; SHIN, E.C.R. ; AKHAWE, D. ; B OEHM, A. ; SAXENA, P. ; SONG, D.: The emperor’s new APIs: On the (in)
secure usage of new client-side primitives. In: Web 2.0 Security and Privacy Worskhop (W2SP) (2010)
[19]
HEISE : HTML5: WHATWG und W3C gehen unterschiedliche Wege. http://www.heise.de/newsticker/meldung/
HTML5-WHATWG-und-W3C-gehen-unterschiedliche-Wege-1650028.html, Juli 2012
[20] IHLENFELD, Jens:
HTML5 kommt 2014, aber mit weniger Funktionen.
http://www.golem.de/news/
w3c-html5-kommt-2014-aber-mit-weniger-funktionen-1209-94698.html, September 2012
[21] IHLENFELD,
Jens:
Welcher
Browser
liegt
vorn?
http://www.golem.de/news/
ie-firefox-oder-chrome-welche-browser-liegt-vorn-1208-93593.html, August 2012
52
[22] INTERNATIONAL TELECOMMUNICATION UNION: Statistics. http://www.itu.int/ITU-D/ict/statistics/, September
2012
[23] JOHNS, M.: HTML5-Security. In: Datenschutz und Datensicherheit-DuD 36 (2012), Nr. 4, S. 231–235
[24] KREMER, Annika:
HTML5 soll 2016 Standard werden.
19692-html5-soll-2016-standard-werden-2012-09-12, September 2012
http://www.gulli.com/news/
[25] LEKIES, S. ; JOHNS, M. ; TIGHZERT, W.: The state of the cross-domain nation. In: Proceedings of the 5th Workshop on
Web 2.0 Security and Privacy (W2SP), 2011
[26] MCARDLE, Robert: HTML5 Overview: A Look At HTML5 Attack Scenarios. http://www.trendmicro.com/
cloud-content/us/pdfs/security-intelligence/reports/rpt_html5-attack-scenarios.pdf, 2011
[27] MICROSOFT CORPORATION: Introduction to Web Storage (Internet Explorer). http://msdn.microsoft.com/en-us/
library/cc197062%28v=vs.85%29.aspx, Mai 2012
[28] MOZILLA FOUNDATION: Same origin policy for JavaScript. https://developer.mozilla.org/en-US/docs/Same_
origin_policy_for_JavaScript, November 2011
[29] MOZILLA FOUNDATION: BrowserQuest – a massively multiplayer HTML5 (WebSocket + Canvas) game experiment.
http://hacks.mozilla.org/2012/03/browserquest/, März 2012
[30] MOZILLA FOUNDATION: DOM Storage. https://developer.mozilla.org/en/DOM/Storage, Mai 2012
[31] MOZILLA FOUNDATION: The X-Frame-Options response header. https://developer.mozilla.org/en-US/docs/The_
X-FRAME-OPTIONS_response_header, März 2012
[32] NATHAN GOOD, Chris Jay H.: The Web Privacy Census. http://law.berkeley.edu/privacycensus.htm, Juni 2012
[33] NET APPLICATIONS: Desktop Browser Market Share. http://www.netmarketshare.com/browser-market-share.
aspx, August 2012
[34] NETSCAPE:
End of Support for Netscape web browsers.
end-of-support-for-netscape-web-browsers/, Dezember 2007
http://blog.netscape.com/2007/12/28/
[35] OWASP: Cross-Site Request Forgery (CSRF). https://www.owasp.org/index.php/CSRF, September 2010
[36] OWASP: Cross-site Scripting (XSS). https://www.owasp.org/index.php/XSS, Dezember 2011
[37] RIVEST, R.L. ; SHAMIR, A. ; ADLEMAN, L.: A method for obtaining digital signatures and public-key cryptosystems. In:
Communications of the ACM 21 (1978), Nr. 2, S. 120–126
[38] RUDERMAN, Jesse: The same origin policy. 2001
[39] RYDSTEDT, G. ; BURSZTEIN, E. ; B ONEH, D. ; JACKSON, C.: Busting frame busting: a study of clickjacking vulnerabilities
at popular sites. In: IEEE Oakland Web 2 (2010)
[40] SCHMIDT, Michael: HTML5 web security. (2012)
[41] STARK, E. ; HAMBURG, M. ; B ONEH, D.: Symmetric cryptography in javascript. In: Computer Security Applications
Conference, 2009. ACSAC’09. Annual IEEE, 2009, S. 373–381
[42] STATCOUNTER: StatCounter Global Stats. http://gs.statcounter.com/, August 2012
[43] SUNBERG, Lars: Keygen attribute. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/
20080714/07ea5534/attachment.txt, Mai 2012
[44] TREGUBENKO, Artemy: Test of localStorage limits/quota. http://arty.name/localstorage.html, Juni 2012
[45] TRIVERO, A.: Abusing HTML 5 Structured Client-side Storage. 2008
[46] W3 CONSORTIUM:
Association of controls and forms.
association-of-controls-and-forms.html, August 2012
http://www.w3.org/TR/html5-author/
53
[47] W3 CONSORTIUM:
Attributes common to form controls.
attributes-common-to-form-controls.html, August 2012
http://www.w3.org/TR/html5-author/
[48] W3 CONSORTIUM: Cross-Origin Resource Sharing. http://www.w3.org/TR/cors/, Juli 2012
[49] W3 CONSORTIUM: HTML5 differences from HTML4. http://www.w3.org/TR/html5-diff/, Juli 2012
[50] W3 CONSORTIUM: The iframe element. http://www.w3.org/TR/html5/the-iframe-element.html, März 2012
[51] W3 CONSORTIUM: Keygen. http://www.w3.org/TR/html5/the-keygen-element.html, Mai 2012
[52] W3 CONSORTIUM: Offline Web applications. http://www.w3.org/TR/html5/offline.html, Juli 2012
[53] W3 CONSORTIUM: Server-Sent Events. http://www.w3.org/TR/eventsource/, April 2012
[54] W3 CONSORTIUM: Session history and navigation. http://www.w3.org/TR/html5-author/history.html, Juli 2012
[55] W3 CONSORTIUM: Tracking Preference Expression (DNT). http://www.w3.org/TR/tracking-dnt/, März 2012
[56] W3 CONSORTIUM: Transferable objects. http://www.w3.org/TR/html5/Overview#transferable-objects, Juli
2012
[57] W3 CONSORTIUM: W3C Technical Report Development Process. http://www.w3.org/2005/10/Process-20051014/
tr, September 2012
[58] W3 CONSORTIUM: Web Cryptography API. http://www.w3.org/TR/WebCryptoAPI/, September 2012
[59] W3 CONSORTIUM: Web Messaging. http://www.w3.org/TR/webmessaging/, Juli 2012
[60] W3 CONSORTIUM: Web Storage. http://www.w3.org/TR/webstorage/, Mai 2012
[61] W3 CONSORTIUM: Web Workers. http://www.w3.org/TR/workers/, Mai 2012
[62] W3 CONSORTIUM: The WebSocket API. http://www.w3.org/TR/websockets/, Mai 2012
[63] W3 CONSORTIUM: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard
and the W3C HTML5 specification. http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/
0119.html, Juli 2012
[64] W3 CONSORTIUM: World Wide Web Consortium. http://www.w3.org/, Mai 2012
[65] WHATWG: This Week in HTML5 – Episode 35. http://blog.whatwg.org/this-week-in-html5-episode-35,
September 2009
[66] WHATWG: FAQ. http://wiki.whatwg.org/wiki/FAQ, August 2012
[67] WHATWG: Session history and navigation. http://www.whatwg.org/specs/web-apps/current-work/multipage/
history.html, August 2012
[68] WHATWG: Web Hypertext Application Technology Working Group. http://www.whatwg.org, Mai 2012
[69] WHATWG: Web Storage.
html, Mai 2012
http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.
[70] WHATWG: Web Workers. http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#
workers, Mai 2012
[71] WIKIPEDIA: Cross-Site Request Forgery. http://de.wikipedia.org/wiki/Cross-Site_Request_Forgery, Juli 2012
[72] WILLIAMS, J. ; WICHERS, D.: OWASP Top 10–2010. In: OWASP Foundation, April (2010)
[73] ZALEWSKI, M.: Browser security handbook. In: Google Code (2010)
54
Anhang
57
A Chat mit Anne van Kesteren
Chatprotokoll vom 11.07.2012
(12:45:43) cheron: What is the intention of the "challenge" attribute of the HTML 5 keygen element?
Are there any use cases/examples?
(12:48:45) annevk: cheron: it influences the generated signature
(12:48:58) annevk: cheron: the use case is mainly supporting some legacy sites that use <keygen>
(12:49:27) annevk: cheron: so maybe we should move the element to the "obsolete" section
(12:52:46) cheron: annevk: ty, this helps me much with my bachelor’s thesis
Kompiliert: 16. Oktober 2012 21:40
58

Full paper - Fachbereich Informatik

Transcription

Similar documents

Musery Endbericht - Eldorado

kommerzielle digitale überwachung im alltag

Leseprobe anschauen - ebooknews

A507_TRAVIC Sign_PPI AG.indd

Vergleich aktueller Peer-to-Peer-Netzwerke

HTML5 und das Framework jQuery Mobile