Nouveau patch supee-6788 comment appliquer le patch

Après des semaines d'attente pour le patch aujourd'hui (27.10.2015), il a été publié: SUPEE-6788

Beaucoup de choses ont été corrigées et sont également encouragées à examiner les modules installés pour d'éventuelles vulnérabilités.

J'ouvre ce post afin d'obtenir des informations sur la façon d'appliquer le patch. Quelles sont les étapes pour appliquer le patch? À ma connaissance, voici les étapes:

1. Correction de modules avec des fonctionnalités d'administration qui ne se trouvent pas sous l'URL d'administration
2. Correction des modules qui utilisent des instructions SQL comme noms de champ ou champs d'échappement
3. Blocs de liste blanche ou directives qui utilisent des variables comme {{config path=”web/unsecure/base_url”}}et{{bloc type=rss/order_new}}
4. Traiter les exploits potentiels avec un type de fichier d'options personnalisé (aucune idée de la façon de procéder)
5. Appliquer le patch

Est-ce la bonne procédure?

En général, vous pouvez appliquer le patch comme tous les précédents. Jetez un œil à la documentation officielle et consultez ce post SE . Mais oui, vous devez vérifier certains points supplémentaires lors de l'application de ce patch. Byte / Hypernode a un bon article à ce sujet.

1. Vérifiez si votre thème est personnalisé template/customer/form/register.phtmlou personnalisé template/persistent/customer/form/register.phtml. Si tel est le cas, assurez-vous qu'il comprend un form_key.
2. Vérifiez si votre thème a une coutume layout/customer.xml. Si tel est le cas, assurez-vous d'appliquer les modifications nécessaires à partir du patch ( customer_account_resetpassworda été remplacé par customer_account_changeforgotten).
3. Utilisez-vous des variables non standard dans les pages CMS, les blocs statiques ou les modèles de courrier électronique? Assurez-vous ensuite de les mettre sur liste blanche. Consultez cette question SE pour savoir comment mettre en liste blanche les variables / blocs.
4. Exécutez-vous le cron.phpvia HTTP? Assurez-vous de mieux l'utiliser cron.sh. Si ce n'est pas possible, assurez-vous au moins d'appeler cron.php via CLI PHP. Si, pour une raison quelconque, vous ne pouvez pas configurer un véritable cronjob et devez l'exécuter via HTTP, consultez cette question SE
5. Assurez-vous que toutes vos extensions utilisent le "nouveau" routage administrateur. Vous pouvez utiliser ce plugin n98-magerun pour vérifier. Vous pouvez également utiliser ce script CLI . Vous pouvez également jeter un œil à cette question SE connexe .
   6. Lorsque toutes vos extensions utilisent le routage administrateur approprié, assurez-vous de désactiver "Activer le mode de compatibilité du routage administrateur" sous Système - Configuration - Admin - Sécurité.
6. Si vous utilisez M2ePro, mettez-le à jour vers la dernière version car les anciennes versions ne fonctionnent pas avec le nouveau patch.

Lors de la mise à jour, assurez-vous de supprimer le fichier dev/tests/functional/.htaccess. Il n'est plus présent dans Magento 1.9.2.2. Le garder signifie que vous êtes toujours vulnérable.

Dans tous les cas, vérifiez votre page avec MageReport après la mise à jour pour voir si tout s'est bien passé.

Il y a aussi un article de blog technique de Piotr , qui décrit les changements critiques.

Il existe un fichier de vérification qui vous aide à identifier les problèmes: https://github.com/gaiterjones/magento-appsec-file-check

J'en ai fait un script CLI. https://github.com/Schrank/magento-appsec-file-check

Pour Nginx, assurez-vous de bloquer l'accès à cron.php et au dossier dev. Nous utilisons ce bloc:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }

Je viens d'appliquer le correctif sur ma 1.10.1 EE et cela provoque des effets secondaires sur les écrans natifs car le cœur n'est pas conforme à APPSEC-1063:

Exemple:

Dans app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

Vous pouvez trouver 2 addFieldToFilterappels non conformes à APPSEC-1063.

Cela brise les grilles Client> Attribut, vous devez donc patcher le patch, en utilisant l'astuce qu'ils recommandent dans le pdf "SUPEE-6788-Technical% 20Details% 20.pdf" dans la section APPSEC-1063

Changer le plusieurs

    $this->addFieldToFilter($field, 0);

(où $ champ contient des instructions sql complexes (CASE .. WHEN THEN ...))

dans

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

La supee-6788-toolbox et les gaiterjones de rhoerr n'ont pas détecté ce genre de problèmes, j'ai vérifié tous les autres -> addFieldToFilter ($ et aucun ne semble être à l'origine du problème.

Autres fichiers de base 1.10 affectés: (trouvés par la supee-6788-toolbox de rhoerr)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php 

Il peut y en avoir plus.