Auch die großen Websites haben so ihre Probleme mit Cross-Site Request Forgeries (CSRF)...
Der
Apple Store sieht zwar wahnsinnig schick aus, aber unter der Haube geht es leicht drunter und drüber. Kein Wunder, denn hier hat offenbar spektakuläres Design Vorrang vor standardisiertem E-Commerce.
Ich weiß ja, wie das läuft: Die Techniker denken sich eine wunderschöne Shop-Architektur aus, gehen aber davon aus, dass es sich um einen regulären Online-Shop handelt, der eben so aussieht wie jeder andere. Dann aber kommen total einfallsreiche Designer und Konzepter und schon passt nichts mehr so richtig in die Architektur rein.
Und dann passieren eben diese kleinen Fehler, die auch zu Sicherheitslücken werden können.
Tools
Die Chrome-Entwicklertools oder ein Web-Proxy wie Charles oder Fiddler reichen völlig aus.
Drink
Zu diesem Hack empfehle ich nach alter
Fravia-Tradition einen Drink:
Eigentlich wollte ich passend zum Thema einen
Appletini empfehlen, aber das erschien mir zu einfach und plakativ. Daher sollte es ein
Scheibel Williams "Edles Fass 350" sein, um mal Äpfel mit Birnen zu vergleichen.
CSRF
Nun aber in medias res:
Eine Cross-Site Request Forgery ist immer dann möglich, wenn durch einen einfachen GET-Request eine (Trans-)Aktion ausgelöst wird, die abhängig vom User-Kontext ist. Am besten lässt sich das am Beispiel erklären:
Im Apple Store kann man sich Produkte in seinen Warenkorb legen, wie in jedem Onlineshop. Dazu klickt man in diesem Fall auf "Hinzufügen"-Buttons an den Produkten. Auch ohne sich einzuloggen, bekommt man von der Site eine Session zugewiesen und hat einen persönlichen Warenkorb, in dem sich dann die Produkte befinden. D.h. Apple setzt einen Cookie im Browser des Users, um ihn wiederzuerkennen, wenn er zum Store zurückkehrt. Die ID im Cookie ist in den Datenbanken von Apple genauso gespeichert wie die Produkte im Warenkorb.
Nun sind die meisten "Hinzufügen"-Buttons im Apple Store aber wie normale Links umgesetzt (was untypisch ist). Sie lösen also beim Klicken normale GET-Requests aus und bewirken dabei aber eine personalisierte Aktion. Nämlich das Schreiben von bestimmten Produkt-IDs in den User-Warenkorb in der Datenbank von Apple.
Der Link für einen Thunderbolt-Gigabit-Ethernet-Adapter ist z.B.
http://store.apple.com/de/addToCart/MD463ZM/A?r=true
Jetzt kommt man nicht direkt drauf, warum das schlimm sein sollte. Aber ein Angreifer kann eben so einen Link auf seiner eigenen Website im Hintergrund aufrufen und legt dadurch in die Apple-Warenkörbe seiner Besucher beliebige Produkte. Dadurch geht zwar keinem User Geld verloren, aber es leuchtet ein, dass das so nicht im Sinne des Erfinders sein kann. Angenommen, ein Angreifer betreibt eine gut besuchte Website, kann er schon für eine erhebliche Menge Warenkorb-Spam sorgen.
Und im Apple Store gibt es keinen Button, um alle Artikel aus dem Einkaufswagen zu entfernen, bei 100 Artikeln könnte das also schon nervig werden.
Exploit
Wie funktioniert das in der Realität? Ziemlich einfach: Wir ermitteln die Links für einzelne Produkte und rufen sie auf unserer "bösartigen" Website im Hintergrund auf. Z.B. so:
<html>
<body>
<img src="http://store.apple.com/de/addToCart/MD463ZM/A?r=true" style="display: none;" />
</body>
</html>
Mit einem einfachen unsichtbaren img-Tag ist das Thema schon erledigt. Spektakulärer wird es natürlich, wenn man etwas teurere Produkte nimmt anstelle von 29-Euro-Adaptern:
Einen Mac Pro mit Monitor im Wert von 11.476 Euro gefällig?
Ein voll ausgestatteter Klobürstenhalter von Apple ist nicht billig, befindet sich aber ohne Zutun des Users in seinem Einkaufswagen.
Gegenmaßnahmen
Um CSRF zu vermeiden, sollte man immer Formulare mit POST-Requests verwenden und in einem hidden field einen User- und Session-spezifischen Hashwert (CSRF-Token) ablegen, der beim Submitten serverseitig überprüft wird.
Die Überprüfung muss dann auch wirklich greifen. Viele Websites richten zwar ein CSRF-Token ein, aber überprüfen es nicht wirklich. Dann greift die Maßnahme natürlich ins Leere.
Ich habe Apple über den Bug informiert, mal sehen, ob sie reagieren.
Ich würde den Bug als nicht kritisch einstufen. Es ist eher ein Spam- als ein Security-Issue.
History
23.01.2015: Issue an Apple gemeldet
26.01.2015: Antwort von Apple, dass ihnen die Lücke bekannt wäre und sie sie untersuchen. Außerdem der Hinweis darauf, dass Apple öffentlich nicht über solche Lücken spricht. Das ist mir wohl bekannt, daher hab ich das ja für sie übernommen...
