forked from molily/javascript-einfuehrung
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathsicherheit.html
More file actions
206 lines (178 loc) · 30.1 KB
/
sicherheit.html
File metadata and controls
206 lines (178 loc) · 30.1 KB
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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
<!DOCTYPE html>
<html lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>JavaScript: Sicherheit</title>
<link rel="stylesheet" href="js-doku.css">
<script type="text/javascript" src="js-doku.js"></script>
</head>
<body>
<div id="nav">
<p>Hier entsteht eine <strong>JavaScript-Dokumentation</strong> von <a href="http://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:zapperlott@gmail.com">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 wurde lange als gefährlich und unsicher angesehen, sodass viele Webautoren auf JavaScript verzichteten und viele Websurfer die Ausführung von JavaScripten deaktivierten. Dieser Panikmache sollen hier neutrale Informationen gegenübergestellt werden, ohne zu behaupten, JavaScript sei per se sicher und harmlos.</p>
<p>Die besagten Ängste hatten verschiedene Gründe. JavaScript wird seit seinem Bestehen auch zur Gängelung und Irreführung der Websurfer eingesetzt. Moderne Browser haben deshalb Gegenmaßnahmen ergriffen, die die Möglichkeiten von JavaScripten in verschiedenen Punkten beschneiden. Diese <strong>Einschränkungen</strong> werden wir auf dieser Seite kennenlernen.</p>
<p>Der Einflussbereich der breit akzeptierten Kerntechniken (ECMAScript, das Browser Object Model sowie das Document Objekt Model) 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 clientseitigen Programmierung, die weit über die besagte Kerntechniken hinausreicht.</p>
<p>Die Browserhersteller sind bemüht, die Fähigkeiten von JavaScript zu erweitern, u.a. indem sie Schnittstellen zu bestehenden Techniken einbauen. Zum Beispiel im Internet Explorer hat JavaScript (JScript) Zugriff auf <em>ActiveX</em>-Objekte und den sogenannten <em>Windows Scripting Host</em>. Darüber sind - zumindest prinzipiell - sicherheitskritische Zugriffe auf den Client-Rechner möglich. Nun sind diese Schnittstellen nicht für jedes Script verfügbar, sondern durch Sicherungsmechanismen geschützt. Weil diese jedoch in der Vergangenheit zu freizügig waren oder nicht hinreichend funktionierten, entstanden unzählige Sicherheitslücken.</p>
<p>Auch wenn der Internet Explorer solche Probleme mittlerweile im Griff hat: Das Beispiel soll ein allgemeines Problem verdeutlichen, das fast alle Browser betrifft, und das bisher zu allen Zeiten. JavaScript ist im Hinblick auf Sicherheit nicht unproblematisch und es ist verständlich, wenn Anwender JavaScript deaktivieren oder dessen Möglichkeiten einschränken.</p>
</div>
<div class="section" id="sicherheitskonzepte">
<h2>Sicherheitskonzepte von JavaScript</h2>
<div id="sandbox" class="subsection">
<h3>Sandbox-Prinzip</h3>
<p>Ein JavaScript verfügt im Vergleich zu anderen Computerprogrammen nur über begrenzte Möglichkeiten. Es operiert im Rahmen eines Browserfenster 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 <em>Sandbox</em>- oder <strong>Sandkastenprinzip</strong>.</p>
<p>Insbesondere kann ein gewöhnliches JavaScript auf einer Webseite kann <strong>keine Dateien auf dem Client-Rechner auslesen</strong>, geschweige denn Änderungen daran vornehmen. Es kann auch keine Betriebssystem- oder Browsereinstellungen ändern oder Software auf dem Client-Rechner 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 id="same-origin-policy" class="subsection">
<h3>Same-Origin-Policy</h3>
<p>Die Same-Origin-Policy (zu deutsch etwa: <em>Grundregel des selben Ursprungs</em>) besagt, dass ein JavaScript eines Dokuments nur auf diejenigen anderen, fremden Dokumente zugreifen darf, die dieselbe Herkunft haben. Mit <em>derselben Herkunft</em> ist kurz gesagt die Domain in der URI des Dokuments gemeint.</p>
<p>Ein JavaScript hat zunächst einmal Zugriff auf das Dokument, an das es gebunden ist und in dessen Kontext es ausgeführt wird. Bei der Verwendung von Frames, Inner Frames 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 URI <code>http://www.example.org/dokument1.html</code> geladen und in einem anderen Frame desselben Framesets die URI <code>http://www.example.org/dokument2.html</code>. Diese beiden Dokumente haben denselben Ursprungsdomain, nämlich <code>www.example.org</code>. Daher können Scripte beider Dokumente gegenseitig auf das jeweils andere Dokument zugreifen, um z.B. Formulardaten oder Cookies auszulesen, über das DOM Änderungen vorzunehmen oder Anwender-Ereignisse zu überwachen.</p>
<p>Wenn die URI 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 ein schwerwiegendes Sicherheitsrisiko bei all denjenigen 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 auslösen und somit Daten vom Webserver empfangen oder an ihn übertragen. Die Same-Origin-Policy sorgt dafür, dass mit <code>XMLHttpRequest</code> nur HTTP-Anfragen an dieselbe Domain gesendet 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 URI <code>http://www.example.net/script.js</code> einbinden. Diesen Einbinden von Scripten von fremden Webservern Gang und Gäbe vor allem zum Einbinden von Online-Werbung und Statistik-Scripten. Aus der Perspektive der Sicherheit ist eine äußerst zweischneidige Praxis: Einerseits ist es ein sehr nützliches Feature, denn es macht z.B. die Nutzung von Webdiensten möglich. Andererseits kann es zu schwerwiegenden Sicherheitslücken führen, 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 id="same-origin-policy-subdomains" class="subsection">
<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 rigide und streng scheinen, ist aber eine wichtige Sicherheitsbarriere. Diese Sperre geht davon aus, dass unter einer Domain verschiede Websites liegen können, 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.</p>
<p>In einem Dokument unter <code>de.example.org</code> wird folgende JavaScript-Anweisung notiert:</p>
<pre class="content-example">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 class="content-example">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 id="local-machine-lockdown" class="subsection">
<h3>Local Machine Zone Lockdown (Internet Explorer)</h3>
<p>Die Same-Origin-Policy lässt einen Punkt außer Acht: Ein Script darf im Kontext der Herkunftsdomain ohne Begrenzung schalten und walten sowie mittels <code>XMLHttpRequest</code> Daten empfangen und versenden. Das kann zu einem schwerwiegenden Problem werden, wenn das Script nicht im Web, sondern <em>lokal</em> ausgeführt wird. <em>Lokal</em> bedeutet, dass das Dokument auf einer Festplatte des Client-Rechners liegt und von dort aus im Browser geöffnet wird. Die URI beginnt dann mit <code>file://localhost/</code>, in der Kurzschreibweise <code>file:///</code>.</p>
<p>Die Konsequenz ist, dass ein solches Script prinzipiell <strong>alle</strong> Dateien auf den erreichbaren Datenträgern auslesen kann (aber nicht ändern - zumindest nicht über <code>XMLHttpRequest</code> alleine). Mit einigen Kniffen können diese abgegriffenen Daten ins Web gesendet werden. Somit ließen sich vertrauliche Daten ausspionieren. Es stellt daher ein grundlegendes Problem dar, wenn fremde Dokumente mit JavaScript auf den eigenen Rechner gelangen.</p>
<p>Der Internet Explorer ab Windows XP mit dem Service Pack 2 stellt daher alle lokalen Dokumente mit Scripten unter Generalverdacht und verhindert ihre Ausführung. Dieser Sicherheitsmechanismus nennt sich <em>Local Machine Zone Lockdown</em>, zu deutsch <em>Sperrung der Zone des lokalen Computers</em>.</p>
<p>Wie sich dieser Generalverdacht auswirkt und wie man den Internet Explorer trotzdem dazu bringen kann, Scripte in lokalen Dokumenten auszuführen, erörtert der Artikel <a href="http://aktuell.de.selfhtml.org/artikel/sonstiges/markoftheweb/" class="anchor-online-page">Umgehung der Sperrung der lokalen Zone</a>.</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 Freiheiten 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="subsection">
<h3>Popup-Blocker</h3>
<p>Ein problematisches Thema ist das Öffnen von neuen Fenster mit <code>window.open</code>. Diese Methode wird unter anderem dazu missbraucht, um sogenannte <strong>Popup-Fenster</strong> (kurz: <em>Popups</em>) mit Werbung zu öffnen, die automatisch und ohne ausdrücklichen Wunsch des Websurfers aufspringen. Das unkontrollierte Öffnen von Fenstern belästigt den Surfer 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. Ältere Browser lassen sich mit entsprechenden Zusätzen nachrüsten. 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="content-example"><script type="text/javascript">
window.open("dokument.html", "fenstername");
</script></pre>
<p>Wenn Sie ein Fenster jedoch im Zuge der JavaScript-Behandlung (<em>Event-Handling</em>) einer Benutzereingabe öffnen, 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 mit eingebetteten Event-Handler-Attributen sähe so aus:</p>
<pre class="content-example"><a href="dokument.html" onclick="window.open(this.href, 'popup')">
Dokument XYZ im eigenen Fenster öffnen
</a>
<button type="button" onclick="window.open('dokument.html', 'popup')">
Dokument XYZ im eigenen Fenster öffnen
</button></pre>
<p>Sie können den <code>click</code>-Handler alternativ gemäß dem <a href="einbindung.html#traditionelles-event-handling">Traditionellen Event-Handling</a> registrieren:</p>
<pre class="content-example">function popupFenster (adresse) {
window.open(this.href, 'popup');
}
window.onload = function () {
document.getElementById("popupLink").onclick = popupFenster;
};</pre>
<p>Vorausgesetzt bei diesem Beispiel ist, dass im HTML-Code ein Element mit <code>id="popupLink"</code> existiert.</p>
<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 zur Unterscheidung tauglich: Manche Webseiten gaukeln dem Browser vor, sie würden ein »erwünschtes« Popup-Fenster als Reaktion auf eine Benutzereingabe öffnen, indem sie z.B. beim Klick irgendwo ins Dokument zusätzlich ein Werbe-Popup öffnen.</p>
<p>Es gibt keine allgemeingültigen Regeln, nach denen die verschiedenen Popup-Blocker arbeiten. Zudem können sie verschieden »scharf« eingestellt werden. Es ist daher schwierig, zuverlässige Aussagen darüber zu treffen, welche Popup-Fenster geblockt und welche zugelassen werden.</p>
<p>Trotzdem ein paar grobe <strong>Empfehlungen</strong>: Sie sollten darauf verzichten, Fenster als Reaktion auf die dokumentweite Ereignisse zu öffnen. Das betrifft die Ereignisse <code>load</code> oder <code>unload</code>, aber auch Mausereignisse wie <code>click</code> oder Tastaturereignisse wie <code>keypress</code> bei zentralen Objekten wie <code>window</code> und <code>document</code> sowie bei den HTML-Elementen <code>html</code> und <code>body</code>. Solche Fenster werden höchstwahrscheinlich geblockt. Wenn Sie punktuell Popup-Fenster öffnen wollen, dann geben sie einem <code>a</code>- oder <code>button</code>-Element einen Event-Handler für das <code>click</code>-Ereignis. Das obige Beispiel illustriert dies.</p>
</div>
<div id="fenstereigenschaften" class="subsection">
<h3>Die Veränderung der Fenstereigenschaften</h3>
<p>Das Öffnen von neuen Fenstern bringt noch weiteres Missbrauchspotenzial und <strong>schwerwiegende Sicherheitsprobleme</strong> mit sich. Ursprünglich war es möglich, dass ein Script volle Kontrolle über das Aussehen und das Verhalten des neuen Fensters hatte. Die <code>window.open</code>-Methode hat für diese Fensteroptionen einen dritten Parameter. Problematische <code>window.open</code>-Aufrufe sehen zum Beispel so aus:</p>
<pre class="content-example">window.open("dokument.html", "popup1", "top=1000,left=1000,width=10,height=10")
window.open("dokument.html", "popup2", "location=no,menubar=no,resizable=no,status=no,toolbar=no")</pre>
<p><code>window.open</code> hatte direkten Einfluss auf die <strong>Größe des Fensters</strong>, dessen <strong>Position auf dem Bildschirm</strong>, aber auch auf die <strong>Anzeige der browsertypischen Bedienelemente</strong>. Auch war es möglich, Fenster ohne Einschränkungen nachträglich in ihrer <strong>Größe und Position</strong> zu verändern, sodass man sie beliebig über den Bildschirm verschieben konnte (mittels <code>window.resizeBy</code>, <code>window.resizeTo</code> sowie <code>window.innerHeight</code> und <code>window.innerWidth</code>). Gleichzeitig ließ sich unterbinden, dass der Anwender das Fenster in der Größe verändern konnte.</p>
<p>Sie können sich den Missbrauch vorstellen, der dadurch ermöglicht wurde: Indem eine winzige oder überdimensionierte Größe und eine Position außerhalb des Bildschirmes angegeben wurde, konnte der Anwender das Fenster nicht sehen geschweige denn es auf die gewohnte Art schließen. Oder das Fenster hüpfte immer weg, sobald es der Anwender schließen wollte.</p>
<p>Das Verstecken der Menü-, Symbol-, Adress- und Statusleisten wurde auf breiter Front missbraucht, um Websurfer vorzugaukeln, er befinde sich auf der Login-Seite einer anderen, ihm bekannten und vertraulichen Webseite. Auf diese Weise werden im großen Stil persönliche Daten gestohlen - im Fachjargon nennt man diesen Datenklau <a href="http://de.wikipedia.org/wiki/Phishing" class="anchor-external">Phishing</a>.</p>
<p>Eine besonders perfide Gänglung des Benutzers erlaubten alte Versionen des Internet Explorers: Mit der Angabe der Fensteroption <code>fullscreen=yes</code> konnte ein Popup-Fenster im Vollbildmodus geöffnet werden. Über einen solchen <em>Kiosk</em>- oder <em>Präsentationsmodus</em> verfügen auch andere Browser, allerdings war es JavaScripten in anderen Browsern nicht erlaubt, diesen selbstständig zu aktivieren. Im Vollbildmodus war auf dem Bildschirm nichts als die Webseite zu sehen, alles andere wurde überlagert.</p>
<p>Neuere Browser schränken aus diesen Gründen die Einflussmöglichkeiten von nicht priviligierten JavaScripten auf die Darstellung von Browserfenstern stark ein. Gewisse Leisten können per JavaScript nicht mehr ausblendet werden oder sind zumindest immer in einer Kompaktdarstellung zu sehen. Insbesondere die <strong>Adressleiste</strong> wird immer angezeigt, sodass der Anwender stets weiß, auf welcher Webseite er sich befindet, und entscheiden kann, ob sie vertrauenswürdig ist. Viele Browser sorgen außerdem dafür, dass das Fenster eine <strong>Mindest- und Maximalgröße</strong> hat, auf dem Bildschirm tatsächlich zu sehen ist und der Anwender dessen <strong>Größe frei verändern</strong> kann.</p>
<p>Aus Gründen der Benutzerfreundlichkeit sei Ihnen ohnehin geraten, die Browser-Bedienelemente nicht zu verbergen. Je nachdem, was Sie im Popup-Fenster anzeigen möchten, ist der Benutzer dankbar, wenn er über die vertrauten Navigationsmöglichkeiten verfügt. Verzichten Sie möglichst darauf, die Browserleisten im dritten Parameter von <code>window.open</code> auszuschalten. Neuere Browser ignorieren viele dieser Angaben ohnehin und bestimmen die Anzeige von Menü und Leisten selbst. Das genaue Resultat können Sie nicht zuverlässig abschätzen, denn diese JavaScript-Einschränkungen unterscheiden sich von Browser zu Browser und sind individuell konfigurierbar.</p>
<p>Die beschriebenen Probleme mit Popup-Fenstern und die Gegenmaßnahmen seitens der Browser haben dazu geführt, dass der Einsatz von Popup-Fenstern nach und nach zurückgegangen ist. Es gibt noch weitere Gründe, warum Popup-Fenster aus der Mode sind. Einer davon ist, dass moderne Browser ihr Fensterkonzept komplett umgemodelt haben. Früher wurde in einem eigenständigen Browserfenster genau ein HTML-Dokument genau dargestellt. Heutzutage bieten die meisten grafischen Browser <strong>Tabbed Browsing</strong>. Das heißt, sie stellen mehrere Dokumente innerhalb eines Fensters dar und machen diese über Registerkarten zugänglich.</p>
<p>Die problematischen Fensterveränderungen, die wir betrachtet haben, verlieren beim <em>Tabbed Browsing</em> ihren Sinn. Da klassische Popup-Fenster das Konzept von Registerkarten durchbrechen, überlassen Browser zunehmend dem Anwender die Wahl, ob <code>window.open</code> ein eigenständiges Fenster oder eine Registerkarte öffnet. Auf deren Darstellung hat der Autor des JavaScriptes immer weniger Einfluss - zu Gunsten des Anwenders.</p>
</div>
<div id="kontextmenue" class="section">
<h3>Kontextmenü und rechte Maustaste</h3>
<p>Als Kontextmenü wird das Aufklappmenü bezeichnet, das üblicherweise dann erscheint, wenn der Anwender ein Element des HTML-Dokuments mit der rechten Maustaste anklickt. Je nach Hardware, Betriebssystem und Browser gibt es noch weitere Möglichkeiten, das Kontextmenü aufzurufen.</p>
<p>Dieses Kontextmenü ist für den Anwender enorm praktisch bei der Bedienung einer Webseite. Im Kontextmenü eines Links kann er zum Beispiel wählen, dass das Linkziel in einem neuen Fenster geöffnet wird oder die Zieladresse in die Zwischenablage kopiert wird.</p>
<p>Dessen ungeachtet versuchen zahlreichen Webseiten, mittels JavaScript die Anzeige dieses Kontextmenüs im gesamten Dokument zu unterbinden. Diese Scripte reagieren dokumentweit auf die Ereignisse <code>contextmenu</code> und <code>onmousedown</code> und unterdrücken die Standardaktion des Browsers. Die Autoren wollen damit verhindern, dass Texte oder Bilder kopiert werden können oder der HTML-Quellcode gelesen werden kann. Meist wollen sie sich damit gegen eine urheberrechtswidrige Weiterverwendung der eigenen Werke schützen.</p>
<p>Es kann nüchtern festgestellt werden, dass das Sperren des Kontextmenüs diesen Zweck nicht zuverlässig erfüllt. Stattdessen richtet es mehr Schaden als Nutzen an. Wer Texte und Bilder kopieren möchte bzw. den Quelltext lesen will, schafft es ohne viel technisches Know-How auch trotz dieser »Rechtsklick-Sperre«.</p>
<p>Neuere Browser haben erkannt, dass das Sperren des Kontextmenüs den Benutzer gängelt und in der gewohnten Bedienung von Webseiten einschränkt. Sie bieten daher in ihrer Konfiguration die Möglichkeit, diese Sperren zu ignorieren. »Rechtsklick-Sperren« werden damit schlichtweg wirkungslos.</p>
<p>Es mag in besonderen Fällen, insbesondere speziellen Webanwendungen, seinen Sinn haben, ein eigenes, angepasstes Kontextmenü bereitzustellen. Aus diesem Grund ermöglichen verschiedene Browser die Behandlung des <code>contextmenu</code>-Ereignisses. Aber auch in dem Fall ist das Unterdrücken des browsereigenen Kontextmenüs nur möglich, wenn eine entsprechende Browsereinstellung es zulässt.</p>
<p>...</p>
</div>
<div id="kontextmenue" class="section">
<h3>Lang laufende Scripte</h3>
<p>..</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>Zonenmodelle, Positivlisten und 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 der JavaScript-Interpreter wird komplett deaktiviert und 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="subsection">
<h3>Internet Explorer</h3>
<p>Der Internet Explorer verfügt über verschiedene <a href="http://support.microsoft.com/kb/174360/de" class="anchor-external">Sicherheitszonen</a>, 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>
<div class="note-box note-box-question">
<p class="note-box-title">Frage von: mschaefer</p>
<div class="note-box-text">Das kann so nicht stimmen, Local Machine Zone Lockdown nicht berücksichtigt?! Wie spielt die darein?</div>
</div>
<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 class="note-box note-box-todo">
<p class="note-box-title">ToDo von: mschaefer</p>
<div class="note-box-text">Screenshots</div>
</div>
</div>
<div id="firefox-seitenspezifisch" class="subsection">
<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/" class="anchor-external">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 class="note-box note-box-todo">
<p class="note-box-title">ToDo von: mschaefer</p>
<div class="note-box-text">Screenshot NoScript</div>
</div>
</div>
<div id="opera-seitenspezifisch" class="subsection">
<h3>Opera</h3>
<p>Im Opera können Sie eine Vielzahl von Einstellung seitenspezifisch anpassen. Navigieren Sie zunächst zur Webseite, für die Sie besondere Einstellungen angeben wollen. Klicken Sie mit der rechten Maustaste auf eine freie Fläche des Dokuments und wählen Sie im Kontextmenü den Eintrag <em>Seitenspezifische Einstellungen...</em>. Unter der Registerkarte <em>Skripte</em> können Sie nicht nur JavaScript für die Seite aktivieren oder deaktivieren, sondern auch verschiedene JavaScript-Einstellungen festlegen:</p>
<p><img src="images/opera-seitenspezifisch.png" width="459" height="398" alt="" /></p>
</div>
<div id="safari-seitenspezifisch" class="section">
<h3>Safari</h3>
<p>...</p>
</div>
</div>
<div id="privilegien" class="subsection">
<h2>Privilegien und Signaturen (Gecko)</h2>
<p>...</p>
</div>
<div id="xss" class="subsection">
<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 (persistent) JavaScript-Code einschmuggeln.</p>
<p>Dieser Code wird mit allen Rechten ausgeführt, die ein JavaScript üblicherweise hat. Handelt es sich um eine per Login geschützte Anwendung, so kann das Scriptdie Benutzer-Beglaubigung missbrauchen und im Namen des Benutzers automatisiert Aktionen vornehmen. Denn das eingeschleuste Script kann HTTP-Anfragen an die Domain versenden, darüber private Daten auslesen, ändern und verschicken. Weder muss der Benutzer davon Notiz nehmen, noch kann die Webanwendung ohne weiteres unterscheiden, ob ein schädliches JavaScript sogenanntes <em>Session-Hijacking</em> betreibt oder der Benutzer selbst Urheber der Aktionen ist.</p>
<p>XSS-Lücken in großen Webanwendungen wie MySpace, Facebook, Orkut, StudiVZ 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 (Phishing) 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 id="footer">
<p><strong>JavaScript-Dokumentation</strong> · <a href="./">Zum Inhaltsverzeichnis</a></p>
<p>Autor: <a href="http://molily.de/">molily</a> · Kontakt: <a href="mailto:zapperlott@gmail.com">zapperlott@gmail.com</a></p>
<p>Lizenz: <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/de/">Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen</a>.</p>
</div>
</body>
</html>