Java Reference
In-Depth Information
eine Anweisung, entweder eine harmlose HTML-Anweisung, die möglicherweise noch
etwas CSS verwendet, oder aber man schleust ein externes Skript oder einen Skriptbefehl
ein, der von folgenden Besuchern ausgeführt wird. Dazu muss der Code natürlich auf dem
Server gespeichert werden, damit folgende Besucher ihn laden. Gästebücher, Foren, Kom-
mentarfunktionen in Shops oder Portalen, soziale Netzwerke etc. bieten sich hier ideal an.
Hat das geklappt, kann man dann mittels des Schadcodes etwa Cookie-Daten der aktuellen
Seite eines neuen Besuchers an einen anderen Server schicken. Und auch die Weiterleitung
an eine andere Webseite funktioniert (sogenanntes Phishing). Wenn die dann gut gemacht
ist, verwechselt ein Anwender die gefakte Seite unter Umständen mit der eigentlich ge-
wünschten Seite (eben Täuschung).
Doch wie kann diese Form der Attacke überhaupt funktionieren? Das geht eigentlich nur,
wenn eine schlecht gemachte Webseite das Einschleusen und persistente Speichern von
solchem Code gestattet. Denken Sie an ein Gästebuch oder ein Kommentarformular, in dem
ein Anwender Sonderzeichen wie
<
,
>
etc. eingeben kann und diese dann vor der Speiche-
rung nicht maskiert werden. Wenn ein anderer Besucher sich die Einträge in dem Gäste-
buch oder die Kommentare ansieht, werden die subversiven HTML- oder Skript-Anweisun-
gen ausgeführt.
Aber hier liegt die Verantwortung zur Verhinderung solcher Attacken in der Verantwortung
des Webseitenerstellers bzw. Webseitenbetreibers. Es ist ja keine Kunst, die kritischen Zei-
chen (insbesondere <) mit einem Suchmechanismus zu inden und auszutauschen (etwa
mit einem regulären Ausdruck), entweder schon im Client oder - natürlich sicherer - auf
dem Server.
XSS ist aber auch im Zusammenhang mit AJAX zu nennen. Denn hier werden Daten unbe-
merkt in eine bestehende Webseite nachgeladen. Und das können auch Skriptbefehle sein.
Allerdings beschränken die Browser AJAX-Nachladeaktionen auf die gleiche Domain, von
der auch die Originalwebseite geladen wurde (Same Origin Policy). Dieses Konzept ist auch
dafür verantwortlich, dass bei normalen Sicherheitseinstellungen ein JavaScript auch nur
Zugrif auf Eigenschaten der Objekte haben darf, die vom selben Ort wie das JavaScript
selbst stammen.
Etwas anderes ist es, wenn solche Skripte bereits in der Seite selbst vom Anbieter einer
Webseite bewusst eingesetzt werden. Aber das werden seriöse Seiten nicht machen und
Anwender müssen sich bewusst sein, dass sie nicht auf kritische Webseiten gehen. Genauso
verhält es sich, wenn ein Anwender Links in einer E-Mail naiv anklickt. Es ist einfach die
Verantwortung eines Anwenders, dass er sich im Haiischbecken Internet nicht bewegt als
würde er im Hallenbad planschen.
11.2.2■Wie kann man seine Skripte schützen?
Nun stellt sich die Frage, ob und wie Sie Ihre eigenen Skripte schützen können? Erweitern
wir die Frage - wogegen wollen Sie Ihre Skripte schützen?
1. Gegen Diebstahl geistigen Eigentums
2. Gegen Veränderung
3. Gegen die Deaktivierung durch den Anwender
Search WWH ::
Custom Search