In der vergangenen Woche hatte ich einen Kunden zu Besuch, der mit dem Design und der Suchmaschinenindexierung seines Shops nicht zufrieden ist. Das Shopsystem ist wenig verbreitet, vielleicht 20 oder 30 Shops, da es nur für eine ganz bestimmte Branche entwickelt wurde.

Vor dem Termin habe ich mir den Shop angeschaut und dabei auch die üblichen Sicherheitslücken abgeklopft. Tja… ;O) Natürlich habe ich schnell die Standard-XSS-Lücke gefunden, ungefilterte Weitergabe von Suchstrings an das Serverscript.

Dem Kunden zeigte ich dann diese XSS-Lücke in seinem Shop. Im ersten Moment wußte er natürlich nicht was dieses XSS ist, aber nachdem ich ihm demonstrierte was mit Cross-Site Scripting möglich ist und welche Gefahren darin stecken, machte es hörbar KLICK in seinem Kopf.

Da es noch ein kleines Problem mit dem Warenkorb gab rief mein Kunde kurzerhand den Entwickler des Shops an, den er persönlich kennt. Erst schilderte er dem Entwickler das Problem mit dem Warenkorb und dann übergab er mir das Telefon, damit ich erkläre welche Sicherheitslücke im Shop steckt.

Ich versuchte dem Entwickler mehrfach zu erklären was XSS ist und welche Möglichkeiten ein Hacker damit hat. Er kannte weder Cross-Site Scripting noch die Abkürzung XSS. Ich sagte ihm das er in den Suchschlitz "><h1>test</h1> eintippen und beobachten möge was der Browser nach dem Suchvorgang anzeigt. Ich hörte ihn tippen und dann war erst einmal Stille am anderen Ende. Die Fragezeichen über seinem Kopf drangen förmlich durchs Telefon… “Aber das läuft doch nur bei dem einen Besucher, nur in seinem Browser?!” Nachdem er das Problem irgendwie nicht verstand und ich die Zeit meines Kunden nicht unnötig verschwenden wollte, verwies ich ihn zu Wikipedia und das er dort nachlesen kann wo die Problematik liegt.

Nach ca. einer Stunde rief mein Kunde dann noch einmal bei dem Entwickler an, um weitere Fragen zu klären. Das erste was der Entwickler sagte war das er das Sicherheitsloch gestopft hätte. Na also, war Wikipedia doch wieder sehr lehrreich.

Auf dieses Unverständnis der Entwickler treffe ich leider immer wieder, wenn es um XSS geht. Sie kennen zwar die übliche Demonstration einer XSS-Lücke, z.B. die mit dem kleinen Hinweis der per <script>alert(‘XSS-Hacker’)</script> im Browser angezeigt wird, aber sie verstehen oft nicht das eben nicht nur solche offensichtlichen Dinge möglich sind.

Wenn es möglich ist ein JavaScript nachzuladen, so ist dies der GAU für die Sicherheit des WebSite-Besuchers. Ist es möglich Inline Frames (iframe) nachzuladen so ist der Hacker noch nicht einmal auf aktiviertes JavaScript angewiesen, um dem Opfer unerwünschte Inhalte unterzuschieben.


Ich habe darüber nachgedacht wie man Entwicklern verdeutlichen kann was XSS in der Praxis bedeutet. Da ich keine echten XSS-Lücken veröffentliche, bleibt nur eine Demo-Seite, auf der XSS zwar live gezeigt wird, aber ohne das jemand zu Schaden kommen kann.

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.


Bei einem der XSS-Demos habe ich mich, wegen des Hackerparagraphen (de.wikipedia.org), gegen das echte JavaScript entschieden…

Von Keyloggern (de.wikipedia.org) hat der eine oder andere sicher schon gehört.

Ein Keylogger ist eine Hard- oder Software, die dazu verwendet wird, die Eingaben des Benutzers an einem Computer mitzuprotokollieren und dadurch zu überwachen oder zu rekonstruieren

(Quelle: de.wikipedia.org)

Keylogger gibt es auch in JavaScript… Nach nur wenigen Minuten fand ich per Suchmaschine ein lauffähiges Stück Ajax-Software, welches mit JavaScript und PHP jegliche Tastatureingaben in eine Datei protokolliert und dies ohne das ein Opfer irgendeinen Hinweis, wie z.B. den Ladebalken des Browsers, beim Laden von WebSites, angezeigt bekommt… eben Ajax (de.wikipedia.org). Das perfide daran: Die Demo-HTML besteht nur aus einem Eingabeformular, in welches das JavaScript per XSS injiziert wird. Zur Aufzeichnung der Tastatureingaben genügt es vollkommen aus die Formularfelder nur auszufüllen, der Senden-Button muß nicht geklickt werden. Wenn ich so einen JavaScript-Keylogger in Aktion sehe und an all die WebSites denke die XSS-Lücken haben…


Entwickler denken leider oft nicht über die vielfältigen Verbreitungsmöglichkeiten von manipulierten Links nach und meinen das nur einzelne Besucher betroffen sind. Die breite Nutzung von Sozialen Netzwerken und der leichtfertige Klick auf einen Link erleichtert dem Hacker sein Geschäft.

Über die genauen Verbreitungsmöglichkeiten schreibe ich im nächsten Beitrag.
Also… Fortsetzung folgt. :O)