Ich wollte Nico Lumma zum Launch von shoppero.com beglückwünschen und wie es sich unter Kollegen gehört per E-Mail noch ein paar Verbesserungswünsche (auch aus sicherheitstechnischer Sicht) zum Launch zumailen. Über die Vorstellung eines sogenannten Adgets in einem Blog und der allgemeinen Kritik am Konzept im E-Commerce Blog (die ich übrigens nur bedingt teile, da ich es gut finde, dass neben Adical auch noch der eine oder andere – ähnliche – Mitbewerber auf den Markt kommt) kam ich auf die Empfehlungsseite bei shopper.com. Dann habe ich ein bißchen rumgebrowst und bin u.a. auf der URL http://shoppero.com/index.php?action=lists&subaction=search_by_letter&letter=t (die ich jetzt absichtlich NICHT verlinke: aktuell ist es so, wenn Ihr dort drauf klickt, findet eine Second Order XSS Attacke (persistentes XSS, auch Type-2 XSS genannt – das die Basis für JavaScript-Viren ist, siehe z.B. den MySpace Wurm vor einigen Jahren) von einem registrierten Nutzer statt, der Eure Session entführt, bitte daher also mit einer frischen Browser-Session ohne irgendwelche anderen offenen Tabs/Logins etc. anschauen!) stehen geblieben. Die folgenden Screenshots sollen einfach mal ohne Worte verdeutlichen, wie gefährlich mangelnde Sicherheit sein kann. Nico ist bereits per E-Mail benachrichtigt, und ich gehe davon aus, dass der Nutzer schnell entfernt werden wird und die potenziellen Bugs geschlossen werden.

Die Thumbs sind auf die Originalgröße verlinkt.

Aufruf der URL. Alles erst mal noch ganz harmlos. Ausgabe der Liste stockt.

Nun wird per XSS ein JS Alert (sieht man hier gerade nicht im Screenshot) ausgegeben.

Meine Session-ID wird angezeigt. Gott sei Dank bin ich nicht dort registriert und auch nicht eingeloggt, sonst hätte der Angreifer eine gültige Session und damit auch möglicherweise einen gültigen Login.

Danach erfolgt ein Redirect auf eine Site des Angreifers.

Das war purer Zufall, dass ich diese Second Order XSS Attacke eines anderen Nutzers entdeckt habe. Diese möchte ich hier dokumentieren, um zu verdeutlichen, wie wichtig es gerade im Bereich E-Commerce, in dem es immerhin um Transaktionen und auch Geld geht, ist, seine Site so sicher wie möglich zu machen. Zur Erklärung: die Site ist per se nicht unsicher. In diesem Beispiel ist es so, dass scheinbar der Blätter-/Anzeigemechanismus der Empfehlungen der User anfällig ist für so genannte second order XSS Attacken. Dh. ein Angreifer konnte wohl in Profildaten oder Produktbeschreibungen speziellen JavaScript-Code hinterlassen. Dieser wird dann bei Durchsicht ausgeführt, wenn ein Nutzer auf obige URL klickt. Das ist deswegen möglicherweise so gefährlich, weil die XSS Attacke genau dort auftritt, wo viele Nutzer vermutlich auch hinkommen werden, nämlich beim Durchblättern der User/Angebote. Anders als bei „normalen“ XSS Attacken, wo der Angreifer direkt einen Nutzer zur Ausführung einer URL bringen muss (z.B. durch Versand einer E-Mail oder wie im gestrigen Beispiel Verkürzung einer URL), kann man hier in aller Seelenruhe den Schadcode in die potenziell verwundbare Applikation einbringen und muss dann nur warten, bis die Nutzer auf diese Seite gehen und kann „die Früchte ernten“, also die Nutzersessions.

UPDATE: für eine „Analyse“ des HTML-Sourcecodes siehe den Folgebeitrag.

UPDATE 2: Auf dem fixmbr Blog, genauer gesagt in den Userkommentaren, scheint man schon bereits gestern Abend auf diese Lücke gestoßen zu sein.