Je pense qu'il sera difficile de trouver une réponse définitive à cette question de savoir pourquoi un jeton CSRF est "nécessaire" dans l'action GET d'ajout au panier de Magento. Je vais essayer d'interpréter son but. Je ne suis en aucun cas un expert en sécurité et c'est mon interprétation de CSRF dans ce contexte particulier.
Le contexte
De owasp.org
Cross-Site Request Forgery (CSRF) est une attaque qui force un utilisateur final à exécuter des actions indésirables sur une application Web dans laquelle il est actuellement authentifié. Les attaques CSRF ciblent spécifiquement les demandes de changement d'état, et non le vol de données, car l'attaquant n'a aucun moyen de voir la réponse à la demande falsifiée.
Un exemple de cette attaque consiste à incorporer une image masquée dans un e-mail ou une autre page Web:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
Le serveur Web ne différencierait pas l'origine de la demande et ajouterait fidèlement l'article au panier de cet utilisateur.
L'objectif de la prévention des attaques CSRF est d'empêcher les demandes de changement d'état . L'ajout d'un article à un panier serait considéré comme un changement d'état. En général, je considérerais qu'il s'agit d'un changement d'état inoffensif par rapport à la soumission d'une commande, au transfert de fonds ou à la mise à jour d'une adresse e-mail.
Concernant les changements d'état et les méthodes HTTP, la RFC 2616 dit ce qui suit:
En particulier, la convention a été établie que les méthodes GET et HEAD NE DEVRAIENT PAS avoir l'importance de prendre une action autre que la récupération. Ces méthodes doivent être considérées comme «sûres».
Magento et CSRF
Magento met en œuvre un mécanisme de prévention CSRF pour les zones d'administration et frontend en utilisant un jeton (clé de formulaire). Je suppose que l'objectif de Magento, en tant que plate-forme destinée à être développée par d'autres développeurs, est de sécuriser toutes les demandes de changement d'état. La raison en est qu'ils n'ont aucune idée de ce que les développeurs d'implémentation ou les extensions tierces peuvent exposer par inadvertance. Il est plus sûr de sécuriser toutes les demandes de changement d'état que d'avoir quelque chose exposé par un module tiers et d'être un mauvais PR pour la plate-forme. Je ne sais pas vraiment si toutes les demandes de changement d'état sont sécurisées contre les attaques CSRF.
Une chose à noter est que Magento n'utilise pas toujours une clé de formulaire pour protéger les demandes de changement d'état. Par exemple, les demandes Supprimer du panier ( /checkout/cart/delete/id/{ID}) et Supprimer l'adresse client ( /customer/address/delete/id/{ID}) sont toutes deux des demandes GET qui transmettent un ID d'entité. Le contrôleur (ou les modèles) se charge ensuite de s'assurer que l'utilisateur est autorisé à supprimer ces enregistrements d'entité (modifier l'état). Ce sont deux cas où Magento ne suit pas la RFC 2616 . Pour être juste, pour certains cas d'utilisation, il peut ne pas être pratique ou nécessaire de le faire.
Il semble que la vérification des clés de formulaire dans la Mage_Checkout_CartController::addActionméthode ait été ajoutée dans la version 1.8. À partir des notes de version, nous avons les éléments suivants à partir:
Problèmes résolus qui auraient pu entraîner une falsification de demande intersite (CSRF) dans la boutique en ligne.
Malheureusement, le langage est vague et le «aurait pu» me porte à croire que cela était dû à l'hypothèse que j'ai énoncée plus tôt: sécuriser les demandes de changement d'état. Il pourrait y avoir une possibilité d'envoyer des paramètres supplémentaires qui provoquent une sorte de comportement involontaire:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
L'idée étant qu'en ajoutant quelque chose au panier, il y a un peu de code (core ou tiers) qui se déclenche lors de l'ajout au panier, par exemple via un événement distribué.
Il semble peu probable qu'une telle vulnérabilité existe dès le départ et si elle le fait, on espère que Magento ferait un meilleur travail de divulgation des détails / risques. Un risque que je pouvais voir est que Magento stocke aveuglément les paramètres de la demande lors de l'ajout au panier dans la product_optionscolonne du tableau des articles de commande client (voir:) info_buyRequest. En théorie, quelqu'un pourrait inciter un groupe d'utilisateurs à ajouter des articles à leur panier avec des paramètres de requête étranges et qui seraient stockés dans la sales_flat_quote_item_optiontable et éventuellement la sales_flat_order_itemtable s'ils sont également en mesure de convertir ces utilisateurs. Cela me semble très peu probable dans la plupart des cas.
Ajouter au panier Problèmes clés du formulaire
L'un des gros problèmes rencontrés par les gens avec une implémentation FPC et des jetons CSRF est qu'ils finissent par être mis en cache. Le premier client qui réchauffe le cache génère le jeton, lorsque le deuxième client obtient un cache HIT, une page contenant le premier jeton des utilisateurs lui est désormais attribuée. Lors de la soumission du formulaire, les jetons ne correspondent pas.
Magento Enterprise utilise des espaces réservés pour rechercher / remplacer les clés de formulaire dans les pages mises en cache. Les implémentations de vernis utiliseront également un ESI partout où une clé de formulaire est utilisée.
Je serais curieux de savoir si certaines des extensions "ajax cart" les plus populaires finissent par vérifier le jeton CSRF lors de leurs demandes d'ajout au panier.
La seule demande de fonctionnalité où je finis par renoncer au jeton CSRF pour l'action ajouter au panier permet de créer des liens d'ajout au panier à utiliser dans des e-mails ou d'autres sites Web (médias sociaux). Parfois, le marketing souhaite que les utilisateurs ajoutent directement un article au panier et le redirigent immédiatement vers le panier ou le paiement. Cela ne peut pas être fait facilement si un jeton CSRF est requis. Je ne recommanderais cela que si vous êtes à l'aise avec le niveau de risque et faites confiance à votre propre code et à tout code tiers.