CSRF Attaque & session Hijack vulnérabilité

Question

Des notes de version 1.8CE Alpha:

  

Le magasin web Magento a Cross Site Request Forgery supplémentaire (CSRF)   protections, ce qui signifie un imposteur ne peut plus usurper l'identité d'un nouveau   client enregistré et effectuer des actions au nom du client.

et

  

Dans les versions antérieures, Magento était vulnérable à une fixation de session   attaque au cours de la procédure d'inscription. Une fois connecté à leur   compte, la session d'un utilisateur enregistré ID n'a pas changé. Par conséquent, si   un attaquant a eu connaissance d'un ID de session non autorisée et si ce   utilisateur enregistre avec succès, l'attaquant a pu prendre en charge la   nouveau compte enregistré. Maintenant, l'ID de session change après succès   l'enregistrement, ce qui rend l'utilisation non autorisée d'un compte impossible.

Si cela est dans les notes de version, et je ne vois pas un point de presse sur les versions antérieures portant sur ce (je cherche au mauvais endroit?) - fait alors que cela signifie que pré-1,8 courant magasins sont potentiellement ouverts à ces vecteurs d'attaque ?

Source: http://www.magentocommerce.com/knowledge-base / entrée / ce-18 après-release-notes

Answer 1

En bref, oui. CE 1.7 est toujours vulnérable à ces attaques spécifiques parce qu'aucun communiqué de sécurité a été émis qui contient un patch.

Dans le cas de ce dernier l'un, une attaque de fixation de la session, le changement est une mise à niveau dans les pratiques de sécurité qui Magento déjà utilisé pour rester en ligne avec les meilleures pratiques de sécurité en vigueur. Pas quelque chose susceptible d'être délivré à CE 1.7 si elles ne délivrent un patch avec les correctifs CSRF.

La vraie question est ce que sont exactement ces vulnérabilités CSRF qui ont été fixés? Sans doute une bonne chose qu'ils ne comprennent pas les détails dans les notes de version, compromettant ainsi encore les versions précédentes, mais il serait bon de savoir pour le bien de rapiéçage implémentations anciennes.

Mise à jour # 1: En arrivant vers Magento pour savoir quand ils émettront des correctifs pour les vulnérabilités ci-dessus, j'ai reçu la réponse suivante:

  

Permettez-moi un peu de temps à la recherche davantage. Je ne sais pas s'il y a des correctifs disponibles pour ces deux éléments, tels qu'ils sont énumérés dans notre système des améliorations de produits et non comme des bugs. Je vais vous mettre à jour lorsque je reçois plus d'informations.

Je vais poster plus de détails retour ici que je les ai, et ferai de mon mieux pour obtenir les correctifs publiés, car il semble qu'il n'y a pas actuellement des patchs existants.

Mise à jour # 2: Après-et-vient avec l'équipe de soutien, j'ai pu obtenir un correctif approprié pour Magento EE 1.12.0.2. Aucun correctif a été publié pour Magento CE 1.7.0.2, et pour autant que le technicien qui avait l'air en intérieurement pour me connaît, il n'y a pas l'intention de libérer un patch officiel pour CE 1.7.x à la place résoudre les problèmes que dans le prochain CE 1.8 libération stable.

En ce qui concerne le fichier de patch spécifique EE, je ne peux pas poster (ou l'outil d'application de patch) ici directement, car il serait très certainement en violation de NDA entre Magento et moi-même personnellement et la société pour laquelle le travail I. Le nom du patch correspondant est: « PATCH_SUPEE-1513_EE_1.12.0.2_v1.sh » - Si vous avez la version Enterprise Edition ou un client à l'aide, vous devriez être en mesure de demander ce patch de l'équipe de soutien Magento avec une note sur les vulnérabilités CSRF qu'il est censé corriger.

Pour les utilisateurs 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 ne comprend que les gros morceaux de code qui modifient les fichiers de code Magento CE 1.7.0.2 de base. En mode normal, il comprend des bits non pertinents des commentaires ajoutés et ajusté le formatage ainsi que les changements de code pertinents. La création de ce nécessaire de modifier manuellement le patch d'origine pour l'appliquer à l'aide de l'outil fourni l'application du correctif, puis en utilisant git pour générer un patch sur la base des modifications appliquées.

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

Pour appliquer le patch, premier cd dans 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 patch spécifique EE inclus les contrôles de validation de forme clé pour les contrôleurs spécifiques de l'entreprise, les modifications de l'entreprise / défaut et les fichiers de modèle entreprise / iphone pour inclure des clés de formulaire dans les formes utilisées pour les actions de contrôleur patchés et fonctionalité supplémentaire Pleine page Cache compte correctement pour les clés de forme passant et repassant sur les pages mises en cache.

DISCLAIMER: Je n'ai pas testé soit le patch EE fourni par Magento, ni le patch j'ai téléchargé sur l'essentiel lié. Le patch fourni dans l'essentiel référencé est fourni avec aucune garantie et peut ou ne peut pas résoudre complètement les vulnérabilités mentionnées dans les CE 1.8 notes de version. En tant que correctif non testé, il n'y a également aucune garantie qu'il fonctionne en tout ou partie. C'est à dire. utiliser à vos propres risques et prendre les mesures nécessaires pour test avant le déploiementà un environnement de production. Si vous trouvez des problèmes avec le patch, laissez-moi savoir et je vais le mettre à jour.

Answer 2

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

  

ce qui signifie un imposteur ne peut plus usurper l'identité d'un client nouvellement enregistré

signifie que jusqu'à présent « un imposteur » pourrait usurper l'identité d'un client nouvellement enregistré.
J'espère qu'il est juste « sémantique », mais je pense que cela veut dire ce que vous craignez que cela signifie.