Warum ist ein CSRF-Schutz für Add-to-Cart erforderlich?

Magento hat seit neueren Versionen einen form_keyals Teil der Add-to-Cart-Aktion, um vor meiner Meinung nach CSRF-Angriffen zu schützen.

Jetzt frage ich mich also, ob es wirklich für diesen Ort benötigt wird und warum oder besser gesagt, vor welchen bestimmten Szenarien es schützen soll.

Ich glaube, es wird schwierig sein, eine endgültige Antwort auf die Frage zu finden, warum ein CSRF-Token in Magentos GET-Aktion in den Einkaufswagen "benötigt" wird. Ich werde versuchen, seinen Zweck zu interpretieren. Ich bin kein Sicherheitsexperte und das ist meine Interpretation von CSRF in diesem speziellen Kontext.

Kontext

Von owasp.org

Cross-Site Request Forgery (CSRF) ist ein Angriff, der einen Endbenutzer dazu zwingt, unerwünschte Aktionen in einer Webanwendung auszuführen, in der er sich gerade authentifiziert. CSRF-Angriffe zielen speziell auf Zustandsänderungsanforderungen ab, nicht auf Datendiebstahl, da der Angreifer keine Möglichkeit hat, die Antwort auf die gefälschte Anforderung zu sehen.

Ein Beispiel für diesen Angriff ist das Einbetten eines versteckten Bildes in eine E-Mail oder eine alternative Webseite:

<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">

Der Webserver würde nicht unterscheiden, wo die Anfrage herkommt, und würde den Artikel getreu dem Warenkorb des Benutzers hinzufügen.

Das Ziel der Verhinderung von CSRF-Angriffen besteht darin, Zustandsänderungsanforderungen zu verhindern . Das Hinzufügen eines Artikels zu einem Warenkorb wird als Statusänderung betrachtet. Im Allgemeinen würde ich dies als harmlose Zustandsänderung gegenüber dem Absenden einer Bestellung, dem Überweisen von Geldern oder dem Aktualisieren einer E-Mail-Adresse ansehen.

In Bezug auf Statusänderungen und HTTP-Methoden besagt RFC 2616 Folgendes:

Insbesondere wurde festgelegt, dass die Methoden GET und HEAD NICHT die Bedeutung haben DÜRFEN, eine andere Aktion als das Abrufen durchzuführen. Diese Methoden sollten als "sicher" angesehen werden.

Magento und CSRF

Magento implementiert mithilfe eines Tokens (Formularschlüssels) einen CSRF-Präventionsmechanismus sowohl für Administrations- als auch für Frontend-Bereiche. Ich gehe davon aus, dass es das Ziel von Magento ist, als Plattform, auf der andere Entwickler aufbauen sollen, alle Zustandsänderungsanforderungen abzusichern . Der Grund dafür ist, dass sie keine Ahnung haben, was die implementierenden Entwickler oder Erweiterungen von Drittanbietern versehentlich preisgeben könnten. Es ist sicherer, alle Zustandsänderungsanforderungen abzusichern, als etwas von einem Drittanbieter-Modul offen zu legen und schlechte PR für die Plattform zu sein. Ich weiß eigentlich nicht, ob alle Zustandsänderungsanforderungen vor CSRF-Angriffen geschützt sind.

Zu beachten ist, dass Magento nicht immer einen Formularschlüssel verwendet, um Zustandsänderungsanforderungen zu schützen. Beispielsweise sind die Anforderungen "Aus Einkaufswagen löschen" ( /checkout/cart/delete/id/{ID}) und "Kundenadresse löschen" ( /customer/address/delete/id/{ID}) beide GET-Anforderungen, die eine Entitäts-ID übergeben. Der Controller (oder die Modelle) sorgen dann dafür, dass der Benutzer berechtigt ist, diese Entitätsdatensätze zu entfernen (Status ändern). Dies sind zwei Fälle, in denen Magento RFC 2616 nicht befolgt . Um fair zu sein, ist dies in einigen Anwendungsfällen möglicherweise nicht praktikabel oder notwendig.

Es scheint, dass die Formularschlüsselüberprüfung in der Mage_Checkout_CartController::addActionMethode in Version 1.8 hinzugefügt wurde. Aus den Release Notes geht Folgendes hervor:

Behobene Probleme, die zu Cross-Site Request Forgery (CSRF) im Webshop hätten führen können.

Leider ist die Sprache vage und das "Hätte" lässt mich glauben, dass dies auf die Annahme zurückzuführen ist, die ich zuvor angegeben habe: Sichere Zustandsänderungsanfragen. Es besteht möglicherweise die Möglichkeit, zusätzliche Parameter zu senden, die zu ungewolltem Verhalten führen:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd

Die Idee ist, dass durch das Hinzufügen von etwas in den Warenkorb ein bisschen Code (Kern oder Drittanbieter) entsteht, der zufällig während des Hinzufügens zum Warenkorb ausgelöst wird, z. B. durch ein Ereignis, das ausgelöst wird.

Es ist unwahrscheinlich, dass eine solche Sicherheitsanfälligkeit bereits vorhanden ist, und wenn dies der Fall ist, würde man hoffen, dass Magento die Details / Risiken besser preisgibt. Ein Risiko, das ich sehen konnte, besteht darin, dass Magento die Anforderungsparameter während des Hinzufügens zum Einkaufswagen in der product_optionsSpalte der Tabelle mit den Kundenauftragspositionen blind speichert (siehe:) info_buyRequest. Theoretisch könnte jemand eine Gruppe von Benutzern in dem Hinzufügen von Elementen in ihre Einkaufswagen mit seltsamen Abfrageparametern Trick und dass und in der sie gespeichert würde sales_flat_quote_item_optionTisch und schließlich die sales_flat_order_itemTabelle , wenn sie sind auch fähig , jene Benutzer zu konvertieren zu bekommen. Dies erscheint mir in den meisten Fällen sehr unwahrscheinlich.

In den Warenkorb legen Formular Schlüsselprobleme

Eines der großen Probleme, mit denen Menschen bei einer FPC-Implementierung und CSRF-Token konfrontiert werden, ist, dass sie am Ende zwischengespeichert werden. Der erste Client, der den Cache erwärmt, generiert das Token. Wenn der zweite Client einen Cache-HIT erhält, erhält er jetzt eine Seite mit dem Token des ersten Benutzers. Beim Absenden des Formulars stimmen die Tokens nicht überein.

Magento Enterprise verwendet Platzhalter, um die Formularschlüssel in zwischengespeicherten Seiten zu suchen bzw. zu ersetzen. Bei Lackimplementierungen wird ein ESI überall dort verwendet, wo ein Formularschlüssel verwendet wird.

Ich wäre gespannt, ob einige der populäreren "Ajax Cart" -Erweiterungen das CSRF-Token während ihrer Anfragen zum Hinzufügen zum Warenkorb überprüfen.

Die einzige Funktionsanforderung, bei der ich auf das CSRF-Token für die Aktion "Zum Warenkorb hinzufügen" verzichte, besteht darin, Links zum Hinzufügen zum Warenkorb zur Verwendung in E-Mails oder anderen Websites (soziale Medien) zu erstellen. Manchmal möchte das Marketing, dass Benutzer einen Artikel direkt in den Warenkorb legen und ihn sofort in den Warenkorb oder zur Kasse weiterleiten. Dies ist nicht einfach möglich, wenn ein CSRF-Token erforderlich ist. Ich würde dies nur empfehlen, wenn Sie mit dem Risikograd vertraut haben und Ihrem eigenen Code und dem Code von Drittanbietern vertrauen.

Nach den Grundsätzen der Webentwicklung ist jede Form von Cross-Site-Request-Forgery (CSRF) oder Cross-Site-Scripting (XSS) unerwünscht und sollte immer vermieden werden.

Was bedeutet das? Für CSRF dürfen keine URLs vorhanden sein, die statusbezogene Daten an und für sich mutieren. Andernfalls könnte ein Angreifer den Inhalt des Einkaufswagens einer Person manipulieren oder Artikel zu ihrer Wunschliste oder zu Vergleichen hinzufügen / daraus entfernen, indem er sie lediglich dazu bringt, auf diese URL zu klicken oder sie zu besuchen (sogar eine Weiterleitung).

Mit Formularschlüsseln können sie das umgehen. Magento generiert einen sitzungsspezifischen Hash und erfordert, dass dieser zusammen mit jeder Datenänderungsanforderung gesendet wird.

Ist das Hinzufügen / Entfernen von Warenkorbelementen ein schwerwiegender Angriffsvektor? Wahrscheinlich nicht für die meisten Websites. Aber es ist trotzdem CSRF und CSRF ist schlecht. Deshalb gibt es form_keyjetzt Werte (ab CE 1.8).