Um XSS und deren Gefahren zu verstehen, habe ich unter http://www.qaker.de/xss_examples ein paar Scripte abgelegt.
Die Scripte enthalten mögliche XSS-Szenarien. Also z.B. Get- oder Post-Variable ungefiltert auf der Seite ausgeben, Get-/Post-Variable ungesichert in einem Forumlar ausgeben sowie GET-/POST-Variable durch strip_tags() (PHP-Code) abgesichert versucht abzusichern.
In jeder der Dateien wird anhand von session_start() eine Session gestartet. Diese legt bekanntlich ein Cookie an, und das werden wir in den folgenden Beispielen dann abfragen und zu dem, in unserem Szenraio genannten Server des Angreifers weiterleiten.
Das wäre dann der hier unter http://www.gwood.de/xss_target/. Es ist mal ein mögliches Ziel für Daten, die aus einer XSS-Attacke abgefragt wurden. Dort wird einfach nur das Inhalt der GET-Variable ausgegeben. Diesen könnte ein Angreifer aber genauso gut aus seinem Logfile lesen oder in einer Datei abspeichern. Also unsichtbar für das Opfer.
Und hier nun erstmal die URL’s zu den unsicheren Seiten:
- GET-Variable ungesichert auf der Seite ausgegeben
- POST-Variable ungesichert auf der Seite ausgegeben
- GET-Variable ungefiltert in einem INPUT-Feld ausgegeben
- POST-Variable ungefiltert in einem INPUT-Feld ausgegeben
- GET-Variable mit Strip-Tags in einem IPNUT-Feld ausgegeben
- POST-Variable mit Strip-Tags in einem IPNUT-Feld ausgegeben
Dann – damit einfacher zu testen und nachzuvollziehen ist, hier noch die PHP-Info-Ausgabe des Webspaces, ok, vielleicht doch nur die Ausgabe der Variable in der php.ini magic_quotes_gpc.
Achja, die GET-/Post-Variablen, die ausgegeben werden heißt übrigens param. Also mit dem Query-String ?param=test sollte test ausgegeben werden.
Soweit erst einmal. Später gibt’s dann – wahrscheinlich hier, oder in einem neuen Beitrag das erste Beispiel 
Noch 2 Werkzeuge
Ich stelle jetzt noch 2 Werkzeuge zur Verfügung, um mehr Komfort beim Testen zu haben.
Erste Versuche:
Nun starten wir einmal ganz einfach. Mit der völlig ungeschützten GET-Ausgabe rufen wir das hier auf.
Es wird ein IFrame auf dem Zielserver (in unserem Fall der von dem bösen Hacker) aufgerufen und die aktuelle Session-ID angehangen.