/
sicherheit.html
149 lines (128 loc) · 17.7 KB
/
sicherheit.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<title>JavaScript: Sicherheit</title>
<meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="js-doku.css">
</head>
<body>
<div id="nav">
<p>Hier entsteht eine <strong>JavaScript-Dokumentation</strong> von <a href="https://molily.de/">molily</a>. Derzeit ist sie noch lückenhaft, wächst aber nach und nach. Kommentare und Feedback werden gerne per <a href="mailto:molily@mailbox.org">E-Mail</a> entgegen genommen.</p>
<p class="contents-link"><a href="./">Zum Inhaltsverzeichnis</a></p>
</div>
<h1>JavaScript: Sicherheit</h1>
<div class="section" id="einleitung">
<h2>Einleitung</h2>
<p>JavaScript wird oftmals als gefährlich und unsicher angesehen, sodass manche Webautoren auf JavaScript verzichten und Webnutzer die Ausführung von JavaScripten beschränken. Tatsächlich ist JavaScript nicht harmlos. JavaScript ist eine vollwertige Programmiersprache und JavaScript-Programme laufen auf Webseiten. Damit stellt sich das größten Einfallstor für schädlichen Code im Web dar.</p>
<p>JavaScript wird seit seinem Bestehen auch zur Gängelung und Irreführung der Nutzer eingesetzt. Moderne Browser haben deshalb Gegenmaßnahmen ergriffen, die die Möglichkeiten von JavaScript in verschiedenen Punkten beschneiden. Diese <strong>Einschränkungen</strong> werden wir kennenlernen.</p>
<p>Der Einflussbereich des Kernes von JavaScript (ECMAScript) ist relativ scharf umrissen. Ein JavaScript, das nur diese Techniken verwendet, hat begrenzte Möglichkeiten und damit ein vergleichsweise geringes Gefahrenpotenzial. Vorausgesetzt ist, dass die Browser <strong>grundlegenden Sicherheitskonzepte</strong> beachten. Auch diese werde im Folgenden vorgestellt.</p>
<p>Wenn Sicherheitslücken in Browsern entdeckt werden, ist in den meisten Fällen JavaScript im Spiel. Ein Teil dieser Lücken ermöglicht ein Umgehen der grundlegenden Sicherheitsbeschränkungen, ein anderer betrifft <strong>JavaScript-Erweiterungen</strong>. Denn JavaScript ist mittlerweile ein Türöffner für vielfältige clientseitige Programmierung, die weit über die Kerntechniken hinausreicht.</p>
<p>Die Browserhersteller sind bemüht, die Fähigkeiten von JavaScript zu erweitern, indem sie Schnittstellen zu bestehenden Techniken einbauen. Darüber sind sicherheitskritische Zugriffe auf den Client-Rechner möglich. Nun sind diese Schnittstellen nicht für jedes Script verfügbar, sondern durch Sicherungsmechanismen geschützt. Wenn diese nicht korrekt funktionieren, entstehen Sicherheitslücken.</p>
</div>
<div class="section" id="sicherheitskonzepte">
<h2>Sicherheitskonzepte von JavaScript</h2>
<div class="section" id="sandbox">
<h3>Sandkastenprinzip</h3>
<p>Ein JavaScript verfügt im Vergleich zu anderen Programmen nur über begrenzte Möglichkeiten. Es operiert im Rahmen eines Browserfensters und eines Dokumentes. Innerhalb dieses strengen Rahmens, in den das Script eingesperrt ist, darf es recht frei schalten und walten, denn es kann nur begrenzten Schaden anrichten. Diese grundlegende Beschränkung nennt sich <strong>Sandkastenprinzip</strong> (englisch <em lang="en">sandbox</em>).</p>
<p>Insbesondere kann ein gewöhnliches JavaScript nicht ohne Zustimmung <strong>Dateien auf dem Rechner des Webnutzers auslesen</strong>, geschweige denn Änderungen daran vornehmen. Es kann auch keine Betriebssystem- oder Browsereinstellungen ändern oder Software installieren.</p>
<p>Es gibt nur einige wenige Ausnahmen, in denen ein JavaScript über Browserfenster und Dokument hinaus operieren kann. Zum Beispiel kann es einige bestimmte Browserfunktionen aufrufen und einfache Dialogfenster sowie weitere Browserfenster öffnen. Diese Ausnahmen, die meist mit gewissen Einschränkungen verbunden sind, werden wir noch kennenlernen.</p>
</div>
<div class="section" id="same-origin-policy">
<h3>Same-Origin-Policy</h3>
<p>Die Same-Origin-Policy (zu deutsch etwa: <em>Grundsatz des selben Ursprungs</em>) besagt, dass ein JavaScript in einem Dokuments nur auf diejenigen anderen Dokumente zugreifen darf, die dieselbe Herkunft haben. Mit <em>derselben Herkunft</em> ist kurz gesagt die Domain in der URL des Dokuments gemeint.</p>
<p>Ein JavaScript hat zunächst einmal Zugriff auf das Dokument, in das es eingebunden ist und in dessen Kontext es ausgeführt wird. Bei der Verwendung von Frames, Inner Frames (iframes) und Popup-Fenstern kann ein Script auch auf andere Dokumente zugreifen. Die Same-Origin-Policy schränkt diese dokumentübergreifenden Zugriffe ein.</p>
<p>Nehmen wir an, in einem Frame wird die URL <code>http://www.example.org/dokument1.html</code> geladen und in einem anderen Frame desselben Framesets die URL <code>http://www.example.org/dokument2.html</code>. Diese beiden Dokumente haben denselben Ursprung, nämlich <code>www.example.org</code>. Daher können Scripte beider Dokumente gegenseitig auf das jeweils andere Dokument zugreifen, z.B. um Formulardaten oder Cookies auszulesen, über das DOM Änderungen vorzunehmen oder Ereignisse zu überwachen.</p>
<p>Wenn die URL des zweiten Dokuments hingegen <code>http://www.example.<strong>net</strong>/dokument2.html</code> lautet, dann sperrt die Same-Origin-Policy den dokumentübergreifenden Zugriff. Denn der Ursprung ist unterschiedlich, einmal <code>www.example.<strong>org</strong></code> und einmal <code>www.example.<strong>net</strong></code>.</p>
<p>Ziel der Same-Origin-Policy ist, dass eine Webseite die Daten einer anderen nicht so einfach abgreifen kann. Dies wäre natürlich kein Problem, wenn die andere Webseite sowieso öffentlich ist. Es wäre hingegen eine schwerwiegende Sicherheitslücke bei Webseiten, die einer Anmeldung bedürfen und vertrauliche Daten anzeigen - zum Beispiel Webmail-Dienste, Communities und sämtliche personalisierbaren Webanwendungen.</p>
<p>Die Same-Origin-Policy greift auch bei <code>XMLHttpRequest</code>, besser unter dem Namen <a href="ajax.html">Ajax</a> bekannt. Mit <code>XMLHttpRequest</code> kann ein Script HTTP-Anfragen senden, Daten an Webserver übertragen und schließlich Daten empfangen. Die Same-Origin-Policy sorgt dafür, dass mittels <code>XMLHttpRequest</code> nur Daten von derselben Ursprungsdomain empfangen werden können.</p>
<p>An einem Punkt greift die Same-Origin-Policy nicht: Ein HTML-Dokument kann mittels <code>script</code>-Element JavaScripte von fremden Domains einbinden. Diese werden mit denselben Rechten ausgeführt wie JavaScripte von derselben Domain. Beispielsweise kann <code>http://www.example.org/dokument1.html</code> das externe Script mit der URL <code>http://www.example.net/script.js</code> einbinden.</p>
<p>Solches Einbinden von Scripten von fremden Webservern ist leider Gang und Gäbe: Online-Werbung, Statistik-Scripte und Social-Media-Widgets werden so eingebunden. Aus der Perspektive der Sicherheit ist eine äußerst fragwürdige Praxis. Einerseits ist es ein nützliches Feature, denn es bringt Webdiensten auf die eigene Webseite. Andererseits ist es ein Sicherheitsrisiko, fremden Code in die eigene Seite einzubinden – wir werden später beim <a href="#xss">Cross-Site-Scripting</a> darauf zurückkommen.</p>
</div>
<div class="section" id="same-origin-policy-subdomains">
<h3>Same-Origin-Policy und Subdomains</h3>
<p>Die Same-Origin-Policy blockt nicht nur den Zugriff, der sogenannte Second-Level-Domains übergreift (z.B. <code>example.org</code> darf nicht auf <code>example.net</code> zugreifen). Die Sperre blockt auch den Zugriff zwischen Subdomains derselben Domains. Das heißt, ein Script in einem Dokument unter <code>de.example.org</code> hat keinen Zugriff auf ein Dokument unter <code>en.example.org</code>, obwohl die Domain dieselbe ist (<code>example.org</code>) und sich bloß die Subdomain unterscheidet (<em>de</em> gegenüber <em>en</em>).</p>
<p>Diese Regelung mag zunächst streng scheinen, ist aber eine wichtige Sicherheitsbarriere. Denn es ist möglich, dass unter einer Domain verschiede Websites liegen, die ihre Daten nicht miteinander teilen wollen. Selbst wenn beide Domains zu einer Site gehören, lassen sich die verschiedenen Domains auf diese Weise kapseln und absichern.</p>
<p>Es gibt jedoch die Möglichkeit, dass ein Dokument einwilligt, dass es für den Zugriff von derselben Domain offen ist. In einem Dokument unter <code>de.example.org</code> wird folgende JavaScript-Anweisung notiert:</p>
<pre>document.domain = 'example.org';</pre>
<p>Damit ist das Dokument für Scripte zugänglich, die auf einer Domain liegen, die auf <code>example.org</code> endet. Also nicht nur für <code>de.example.org</code>, sondern auch für <code>en.example.org</code> oder <code>hildegard.de.example.org</code>.</p>
<p>Dieses Schema gilt nicht nur für Second-Level-Domains, sondern für beliebige Subdomains. Ein Script unter <code>hildegard.de.example.org</code> kann folgende Anweisung notieren:</p>
<pre>document.domain = 'de.example.org';</pre><p>Damit erlaubt es den Zugriff z.B. von <code>mechthild.de.example.org</code> und allen anderen Domains, die auf <code>de.example.org</code> enden.</p>
</div>
</div>
<div class="section" id="browser-schutzmechanismen">
<h2>Browser-Einschränkungen und Schutz vor schädlichen JavaScripten</h2>
<p>JavaScript hat zwar keine vollständige Kontrolle über den Client-Rechner und den Browser, besitzt aber einige Möglichkeiten des Missbrauchs, mit denen der Benutzers irregeführt, belästigt und gegängelt werden kann. Mittlerweile besitzen die Browser eingebaute Schutzmechanismen, die gewisse Fähigkeiten von JavaScripten beschränken. Sie sollten diese kennen, denn sie werden bei der JavaScript-Entwicklung früher oder später an diese Grenzen stoßen.</p>
<div id="popup-blocker" class="section">
<h3>Popup-Blocker</h3>
<p>Ein Problem ist das Öffnen von neuen Fenster mit <code>window.open()</code>. Diese Methode wird dazu missbraucht, um sogenannte <strong>Popup-Fenster</strong> (kurz: <em>Popups</em>) mit Werbung zu öffnen, die automatisch und unerwünscht aufspringen. Das unkontrollierte Öffnen von Fenstern belästigt die Nutzer nicht nur, sondern ist auch ein Sicherheitsproblem, denn es kann den Browser lahmlegen oder sogar zum Abstürzen bringen.</p>
<p>Aus diesem Grund haben mittlerweile alle Browser einen sogenannten <strong>Popup-Blocker</strong> eingebaut. Diese Blocker erlauben das Öffnen von Fenstern mittels JavaScript nur, wenn damit <em>auf eine Benutzereingabe reagiert wird</em>. Wenn sie also einfach <code>window.open()</code> aufrufen, werden die meisten Popup-Blocker das Öffnen des Fensters unterbinden:</p>
<pre class="erroneous">
<script>
window.open('dokument.html', 'fenstername');
</script>
</pre>
<p>Wenn Sie jedoch ein Fenster als Reaktion auf eine Benutzereingabe öffnen (siehe <a href="event-handling-grundlagen.html">Event-Handling</a>), erlauben es die Popup-Blocker üblicherweise. So können Sie beispielsweise ein <code>a</code>-Element mit einem <code>click</code>-Handler versehen. Ein einfaches Beispiel sähe so aus:</p>
<pre>
<a href="dokument.html" id="popup-link">
Dokument XYZ im eigenen Fenster öffnen
</a>
</pre>
<p>Das JavaScript dazu (siehe <a href="event-handling-fortgeschritten.html">Fortgeschrittene Ereignis-Verarbeitung</a>):</p>
<pre>
function öffnePopupFenster(event) {
window.open(event.target.href, 'popup');
}
document.getElementById("popup-link")
.addEventListener('click', öffnePopupFenster, false);
</pre>
<p>Popup-Blocker versuchen zwischen <em>erwünschten</em> und <em>unerwünschten</em> Popup-Fenstern zu unterscheiden. Ein Browser kann nicht zuverlässig unterscheiden, ob ein Fenster vom Anwender erwünscht ist oder nicht. Das angesprochene Kriterium der <em>Benutzereingabe</em> (z.B. ein Mausklick auf ein Element) ist nur bedingt tauglich: Manche Webseiten gaukeln dem Browser vor, sie würden ein »erwünschtes« Popup-Fenster als Reaktion auf eine Benutzereingabe öffnen, indem sie beim Klick irgendwo ins Dokument ein Werbe-Popup öffnen.</p>
<p>Es gibt keine allgemeingültigen Regeln, nach denen die verschiedenen Popup-Blocker arbeiten. Um Popup-Blocker möglichst zu umgehen, sollten Sie Fenster nur in Event-Handlern für das <code>click</code>-Ereignis bei <code>a</code>- oder <code>button</code>-Elementen öffnen. Das obige Beispiel illustriert dies.</p>
</div>
</div>
<div class="section" id="browser-konfiguration">
<h2>Browser-Einschränkungen konfigurieren</h2>
<p>… an welchen Stellen man das JavaScript-Verhalten der Browser einstellen kann.</p>
<p>IE 8: Extras > Popup-Blocker > Popupblockereinstellungen; Internetoptionen > Erweitert; Internetoptionen > Sicherheit > [Zone] > Skripting / Verschiedenes</p>
<p>Firefox 3.0: Extras > Einstellungen > Inhalt > JavaScript aktivieren > Erweitert…</p>
<p>Opera: Tools > Preferences > Advanced > Content > JavaScript Options…</p>
</div>
<div class="section" id="seitenspezifische-einstellungen">
<h2>Seitenspezifische Einstellungen</h2>
<p>Ein wichtiges Sicherheitsfeature von Browsern sind Website-spezifische JavaScript-Einstellungen. Je nachdem, welche Website angesurft wird, wird die Ausführung von JavaScripten uneingeschränkt zugelassen, nur eingeschränkt zugelassen oder Scripte gar nicht ausgeführt. Dies trägt dem Umstand Rechnung, dass JavaScript als Haupteinfallstor für die Ausnutzung von Browser-Sicherheitslücken dient, zur Gängelung des Anwenders missbraucht wird oder enfach unerwünschte Werbung einbindet.</p>
<p>Diese seitenspezifischen Einstellungen sind von Browser zu Browser unterschiedlich umgesetzt und betreffen nicht nur JavaScript, sondern auch andere sicherheits- und datenschutzkritische Techniken wie Cookies und Plugins.</p>
<div id="internet-explorer-seitenspezifisch" class="section">
<h3>Internet Explorer</h3>
<p>Der Internet Explorer verfügt über verschiedene Sicherheitszonen, die standardmäßig an gewisse Einstellungen gekoppelt sind. Eine normales HTML-Dokument im World Wide Web liegt in der <em>Internetzone</em>, ein Dokument auf dem lokalen Rechner oder im lokalen Netzwerk in der Zone <em>Lokales Intranet</em>.</p>
<p>Daneben existieren zwei Zonen, zu denen der Anwender eigenständig Webadressen und Netzwerk-Pfade hinzufügen kann: <em>Vertrauenswürdige Sites</em> und <em>Eingeschränkte Sites</em>. Dies erlaubt dem Anwender beispielsweise, für die Internetzone eher restriktive Sicherheitseinstellungen zu wählen, die dann für bestimmte Seiten gelockert werden können.</p>
</div>
<div id="firefox-seitenspezifisch" class="section">
<h3>Firefox</h3>
<p>Mozilla Firefox verfügt intern über seitenspezifische Einstellungen, bietet standardmäßig aber keine Menü an, über das der Anwender die Einstellungen komfortabel regulieren könnte. Der Firefox-Zusatz <a href="http://noscript.net/">NoScript</a> erfreut sich jedoch einiger Verbreitung. Dieser erlaubt das seitenweise Erlauben oder Verbieten der Ausführung von JavaScripten und kann Scripten weitere Beschränkungen auferlegen.</p>
</div>
<div id="safari-seitenspezifisch" class="section">
<h3>Safari</h3>
<p>…</p>
</div>
</div>
<div id="xss" class="section">
<h2>Cross-Site Scripting (XSS)</h2>
<p>Cross-Site Scripting, abgekürzt XSS, ist das Einschleusen von fremden, möglicherweise schädlichen JavaScripten in eine Website. Es handelt sich weniger um ein Sicherheitsproblem innerhalb von JavaScript, sondern um eine Sicherheitslücke in fehlerhaften Webanwendungen. Wenn Webanwendungen Daten aus nicht vertrauenswürdigen Quellen (z.B. aus Formulareingaben oder HTTP-Parametern) ungefiltert ins HTML einbauen, so können Angreifer schlimmstenfalls dauerhaft JavaScript-Code einschmuggeln.</p>
<p>Dieser Code besitzt alle Zugriffsrechte, die ein JavaScript auf der Website üblicherweise hat. Handelt es sich um eine per Login geschützte Anwendung, so kann das Script im Namen des Benutzers Aktionen vornehmen. Denn ein eingeschleustes Script kann HTTP-Anfragen versenden, private Daten auslesen, ändern und verschicken. Der Benutzer nimmt davon meist keine Notiz. Die Webanwendung kann nicht einfach unterscheiden, ob der Benutzer selbst Urheber der Aktionen ist oder ein schädliches JavaScript.</p>
<p>XSS-Lücken in großen Webanwendungen wie Facebook und Twitter haben spektakuläre JavaScript-Würmer möglich gemacht. Diese pflanzten sich innerhalb der Website z.B. über Benutzerprofile fort, konnten private Daten auslesen oder löschen und damit großen Schaden anrichten. Es gibt auch XSS-Würmer, die andere Domains mit derselben Webanwendung (z.B. der Blogsoftware WordPress) infizierten und sich so über Webserver hinweg verbreiteten.</p>
<p>Um XSS-Lücken zu vermeiden, ist eine sorgfältige Prüfung, Filterung und Entschärfung aller nicht vertrauenswürdiger Daten nötig, die in den HTML-, CSS- und JavaScript-Code server- oder clientseitig eingebaut werden. …</p>
</div>
<div class="sequence-navigation">
<p class="next"><a href="ajax.html" rel="next">Serverkommunikation und dynamische Webanwendungen (Ajax)</a></p>
<p class="prev"><a href="css.html" rel="prev">Zusammenarbeit mit CSS</a></p>
</div>
<div id="footer">
<p><strong>JavaScript-Dokumentation</strong> · <a href="./">Zum Inhaltsverzeichnis</a></p>
<p>Autor: <a href="https://molily.de/">molily</a> · Kontakt: <a href="mailto:molily@mailbox.org">molily@mailbox.org</a></p>
<p>Lizenz: <a rel="license" href="https://creativecommons.org/licenses/by-sa/3.0/de/">Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 3.0</a></p>
<p><a href="https://github.com/molily/javascript-einfuehrung">JavaScript-Einführung auf Github</a></p>
<p>Kostenloses Online-Buch und E-Book:<br><a href="https://testing-angular.com" lang="en" hreflang="en">Testing Angular – A Guide to Robust Angular Applications</a> (englisch)</p>
</div>
<script src="js-doku.js"></script>
</body>
</html>