Wir waren jung und wir brauchten schnell Datenschutzbestimmungen …

Ich bin gerade noch dabei, die Resonanz im Einzelnen auszuwerten, aber eines nur kurz, weil es wichtig ist: Selbstverständlich geht es bei Shoppero überhaupt nicht darum, dass wir die Userdaten an Dritte verkaufen. Diesen Passus streichen wir am Montag aus den Datenschutzbestimmungen, denn er ist für uns absolut unwichtig. Warum er drin stand? Wir waren jung und brauchten schnell Datenschutzbestimmungen.

 

Nico Lumma in „Am Tag danach“ auf dem shopperco.com Blog.

 

Ich finde es gut, dass dieser Passus gestrichen wird. Es sei noch mal gesagt, dass ich nichts gegen Werbezusendungen Dritter habe, aber dann mit bewusstem Einverständnis der User. Zu „Wir waren jung und brauchten schnell Datenschutzbestimmungen“ will ich jetzt lieber mal nichts sagen, und es auch dabei bewenden lassen. Ich wünsche viel Erfolg zu diesem teils neuartigen Konzept und hoffe, dass shoppero.com erfolgreich sein wird. Jochen Krisch von Exciting E-Commerce erläutert, was an diesem Konzept so besonders ist – ich bin gespannt, ob und wie es sich in der Zukunft bewährt.

 

Grundsätzlich sollte man sich als Nutzer jedoch AGBs, Datenschutzbestimmungen und sonstige Regelungen eines Services, den man in Anspruch nehmen möchte, genau durchlesen, bevor man einen Service in Anspruch nimmt. Und Betreiber sollten die Investition zur Ausarbeitung von AGBs/Datenschutzbestimmungen nicht scheuen, um späteren Ärger zu vermeiden.

shoppero.com gleich erstes Opfer von Second Order XSS Attacks

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.