Vulnérabilité d'attaque CSRF et de détournement de session


12

À partir des notes de version 1.8CE Alpha:

La boutique en ligne Magento dispose de protections supplémentaires Cross Site Request Forgery (CSRF), ce qui signifie qu'un imposteur ne peut plus se faire passer pour un client nouvellement enregistré et effectuer des actions au nom du client.

et:

Dans les versions antérieures, Magento était vulnérable à une attaque de fixation de session pendant le processus d'enregistrement. Après s'être connecté à leur compte, l'ID de session d'un utilisateur enregistré n'a pas changé. Par conséquent, si un attaquant avait connaissance d'un ID de session non autorisé et si cet utilisateur s'enregistre avec succès, l'attaquant a pu reprendre le compte nouvellement enregistré. Désormais, l'ID de session change après une inscription réussie, rendant impossible toute utilisation non autorisée d'un compte.

Si cela se trouve dans les notes de publication et que je ne vois pas de version ponctuelle sur les versions précédentes corrigeant cela (est-ce que je cherche au mauvais endroit?) - cela signifie-t-il que les magasins pré-1.8 actuels sont potentiellement ouverts à ces attaques vecteurs ?

Source: http://www.magentocommerce.com/knowledge-base/entry/ce-18-later-release-notes


Je viens de mettre à jour ma réponse ci-dessous avec des détails sur l'obtention d'un correctif pour ces vulnérabilités.
davidalger

Réponses:


9

Bref, oui. CE 1.7 est toujours vulnérable à ces attaques spécifiques car aucune version de sécurité n'a été publiée contenant un correctif.

Dans le cas de ce dernier, une attaque de fixation de session, le changement est une mise à niveau des pratiques de sécurité que Magento utilisait déjà pour rester en ligne avec les meilleures pratiques de sécurité actuelles. Pas quelque chose susceptible d'être délivré à CE 1.7 s'ils émettent un correctif avec les correctifs CSRF.

La vraie question est de savoir quelles étaient exactement ces vulnérabilités CSRF qui ont été corrigées? Sans doute une bonne chose qu'ils n'incluent pas de spécificités dans les notes de mise à jour, compromettant ainsi davantage toutes les versions précédentes, mais ce serait bien de savoir pour patcher les anciennes implémentations.

MISE À JOUR # 1: En contactant Magento pour savoir quand ils publieront des correctifs pour les vulnérabilités ci-dessus, j'ai reçu la réponse suivante:

Permettez-moi un peu de temps pour approfondir mes recherches. Je ne sais pas si des correctifs sont disponibles pour ces deux éléments, car ils sont répertoriés dans notre système comme des améliorations de produit et non comme des bogues. Je vous mettrai à jour lorsque j'obtiendrai plus d'informations.

Je posterai plus de détails ici au fur et à mesure que je les obtiendrai, et je ferai de mon mieux pour obtenir des correctifs car il semble qu'il n'y ait actuellement aucun correctif.

MISE À JOUR # 2: Après des allers-retours avec l'équipe de support, j'ai pu obtenir un correctif approprié pour Magento EE 1.12.0.2. Aucun correctif n'a été émis pour Magento CE 1.7.0.2, et pour autant que le technicien qui a examiné en interne pour moi le sache, il n'est pas prévu de publier un correctif officiel pour CE 1.7.x au lieu de résoudre les problèmes uniquement dans le prochain CE 1.8 version stable.

En ce qui concerne le fichier de correctif spécifique à EE, je ne peux pas le poster (ou l'outil d'application de correctif) ici directement car il serait sans aucun doute en violation de la NDA entre Magento et moi-même personnellement et la société pour laquelle je travaille. Le nom du correctif correspondant est: "PATCH_SUPEE-1513_EE_1.12.0.2_v1.sh" - Si vous avez l'édition Enterprise ou un client l'utilisant, vous devriez pouvoir demander ce correctif à l'équipe de support Magento avec une note sur les vulnérabilités CSRF qu'il est censé corriger.

Pour les utilisateurs de CE 1.7.0.2, j'ai pris la liberté de générer un fichier de patch (basé sur le patch fourni par Magento) qui comprend uniquement les morceaux de code qui modifient les fichiers de code de base de Magento CE 1.7.0.2. En règle générale, il inclut des bits non pertinents de commentaires ajoutés et un formatage ajusté ainsi que les modifications de code pertinentes. Pour le créer, vous devez modifier manuellement le correctif d'origine pour l'appliquer à l'aide de l'outil d'application de correctif fourni, puis utiliser git pour générer un correctif en fonction des modifications appliquées.

Le fichier patch que j'ai créé peut être téléchargé à partir de cet essentiel: https://gist.github.com/davidalger/5938568

Pour appliquer le patch, commencez par cd à la racine de votre installation Magento et exécutez la commande suivante: patch -p1 -i ./Magento_CE_1.7.0.2_v1-CSRF_Patch.diff

Le correctif spécifique à EE comprenait des vérifications de validation des clés de formulaire pour les contrôleurs spécifiques à l'entreprise, des modifications aux fichiers de modèle d'entreprise / par défaut et d'entreprise / iphone pour inclure les clés de formulaire dans les formulaires utilisés pour les actions du contrôleur corrigé, et des fonctionnalités supplémentaires de cache de page complète pour prendre correctement en compte passer des clés de formulaire dans les deux sens sur les pages en cache.

AVERTISSEMENT: je n'ai pas testé le correctif EE fourni par Magento ni le correctif que j'ai téléchargé sur l'essentiel lié. Le correctif fourni dans l'essentiel référencé est fourni SANS GARANTIE et peut ou peut ne pas résoudre complètement les vulnérabilités référencées dans les notes de publication CE 1.8. En tant que patch non testé, il n'y a également aucune garantie qu'il fonctionne en tout ou en partie. C'est à dire à vos risques et périls, et faites preuve de diligence raisonnable pour tester avant de déployer dans un environnement de production. Si vous rencontrez des problèmes avec le patch, faites-le moi savoir et je le mettrai à jour.


1
La sécurité par l'obscurité n'est pas une bonne idée. Ils devraient le rendre public afin que chacun puisse patcher son installation. De plus, une simple différence entre les deux versions devrait vous donner une assez bonne impression sur le fonctionnement de l'attaque et la correction des anciennes installations. Par conséquent, les informations sont de toute façon diffusées.
Darokthar

1
D'accord, l'obscurité n'est pas du tout une bonne sécurité, et je n'essayais certainement pas de l'indiquer. Cependant, une divulgation responsable doit être prise en compte. Pour autant que nous sachions, les vulnérabilités auraient pu être soumises à Magento des semaines avant la publication de EE 1.13 et CE 1.8a1. FWIW, je contacterai des gens de Magento pour savoir s'ils ont encore des correctifs pour EE 1.12 et quels sont les plans pour les installations 1.7; spécifiquement pour les vulnérabilités CSRF.
davidalger

Surveillons une mise à jour et modifions la question / réponse en conséquence si un correctif est publié. Merci.
philwinkle

Je viens de publier une mise à jour avec une réponse préliminaire que j'ai reçue de Magento. Il semble qu'il n'y ait actuellement aucun correctif, donc je vais voir ce que je peux faire à ce sujet. Je vais certainement vous tenir au courant… ici et peut-être aussi sur mon twitter.
davidalger

2

Je ne suis pas sûr à 100% car je n'ai pas pu reproduire le problème mais

ce qui signifie qu'un imposteur ne peut plus se faire passer pour un client nouvellement enregistré

signifie que jusqu'à présent, un imposteur pouvait se faire passer pour un client nouvellement enregistré.
J'espère que ce n'est que de la «sémantique» mais je pense que cela signifie ce que vous craignez.


jusqu'à présent, signifie fixe en 1.8 - ou que voulez-vous dire?
Fabian Blechschmidt

ouais ... c'est ce que je veux dire.
Marius
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.