Magento a publié un nouveau correctif de sécurité pour M1 et des mises à jour pour M1 et M2.
Quels problèmes dois-je rechercher lors de la mise à niveau ou de l'application de ce correctif?
SUPEE-10570, Magento Commerce 1.14.3.8 et Open Source 1.9.3.8 contiennent plusieurs améliorations de sécurité permettant de fermer l’exécution de code à distance (RCE), le script intersite (XSS) et d’autres problèmes. Ces versions incluent également de petits correctifs fonctionnels répertoriés dans la notes de version.
MAGENTO 2.2.3, 2.1.12 ET 2.0.18 MISE À JOUR DE SÉCURITÉ
Magento Commerce et Open Source 2.2.3, 2.1.12 et 2.0.18 contiennent de nombreuses améliorations de sécurité permettant de fermer les scripts XSS (Cross-Site Scripting), l’exécution de code à distance par les utilisateurs authentifiés (Admin) et d’autres vulnérabilités. Les versions incluent des correctifs fonctionnels supplémentaires. Pour en savoir plus sur les correctifs fonctionnels, veuillez consulter les Notes de publication pour Magento Commerce 2.0.18, 2.1.12, 2.2.3 et Magento Open Source 2.0.18, 2.1.12, 2.2.3.
Réponses:
Voici la liste des fichiers modifiés par le correctif SUPEE-10570:
MODIFIER
Enfin, après le déploiement sur mon site Web prod (CE 1.7.0.2), j’ai remarqué un problème critique de blocage (processus de commande bloqué).
Le contexte: après l’étape 1 de l’adresse, je crée directement ET connecte le client, il ne devrait voir que la prochaine étape de paiement.
Le problème: après supee-10570, le processus de commande est interrompu après l'étape 1 (en cas de création de compte) et le client est redirigé vers la page d'accueil (avec un panier vide + déconnecté) = impossible de réaliser sa commande.
Le correctif d’urgence: si vous rencontrez un problème similaire avec votre commande / session client, commentez les lignes 414 à 430 de app / code / core / Mage / Core / Modèle / Session / Abstract / Varien.php (celles ajoutées par le patch , voir ci-dessous).
EDIT (2)
Je pense que la condition suivante retournera toujours false (Mage_Core_Model_Session_Abstract_Varien aux lignes 414 à 419, en particulier les lignes 417 + 418).
VALIDATOR_PASSWORD_CREATE_TIMESTAMP sera toujours supérieur à VALIDATOR_SESSION_EXPIRE_TIMESTAMP. L'horodatage de session "expiration" est redéfini lors de la création du compte, donc inévitablement plus ancien que la session init.
Ainsi, par exemple, si vous créez le client lors du paiement, le résultat sera false et le client sera simplement expulsé (= terminer le paiement, rediriger vers la page d'accueil et le panier vide). Plutot mauvais.
J'ai signalé ce problème à l'équipe de magento. Je vais donner des commentaires ici dès que possible.
EDIT (3)
Un nouveau correctif est wip (sur la page de téléchargement du correctif magento, il est écrit "SUPEE-10570 pour CE 1.7.0.0 - MISE À JOUR DU PATCH ATTENDUE, NE PAS UTILISER (0,06 Mo)").
EDIT (4) ~ 1 mois après le signalement du problème de blocage initial
Salut! J'espère que vous êtes tous des biens (et espérons que vous n'avez pas conservé l'état initial du patch jusqu'à présent, à moins que vos revenus commerciaux n'aient probablement sérieusement diminué ^^).
J'ai remarqué la phrase suivante de la page officielle: "Magento fournit maintenant un correctif mis à jour (SUPEE-10570v2) qui ne provoque plus ce problème. Notez cependant que ce nouveau correctif ne protège plus contre deux problèmes liés au traitement de la session problèmes de sécurité contre lesquels le correctif SUPEE-10570 est protégé. " de la page officielle supee-10570.
Sur la page de publication, nous pouvons enfin trouver le fichier v2 (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).
J'ai étudié les modifications dans les détails. Enfin, il semble que l’équipe de magento a décidé de supprimer une partie du correctif liée à la sécurité. Espérons que cette faille de sécurité ne causera pas de dommages graves (sa note critique est basse).
Après avoir restauré la v1 + appliquer la v2, veillez à ce que les fichiers suivants soient rétablis dans leur état initial (avant l'application de la v1):
PS: évidemment, d’autres fichiers sont également modifiés, veuillez vérifier en conséquence.
la source
app/etc/applied.patches.list
(je ne sais pas si c'était dans les notes de publication depuis le début)
Problèmes connus
Ces deux problèmes connus sont associés à l'utilisation de balises HTML dans l'attribut SKU d'un produit:
Invalid value in SKU column. HTML tags are not allowed.
HTML tags are not allowed in SKU attribute.
De notes de patch :
Si le correctif ne parvient pas à s’appliquer lorsqu’il corrige
lib/Zend/Mail/Transport/Sendmail.php
, cela pourrait signifier que votre installation de Magento avait déjà été corrigée avec SUPEE-9652v1 au lieu de SUPEE-9652v2. La solution recommandée consiste à remplacer le correctif SUPEE-9652v1 et à appliquer SUPEE-9652v2 avant d’appliquer SUPEE-10570.la source
J'ai eu le même problème que @DarkCowboy après avoir appliqué le correctif à Magento CE 1.7.0.2.
Après avoir choisi de vous enregistrer en tant que nouveau client lors de la validation de votre commande, la commande crée à la fois la commande et le client, mais au lieu d’afficher la page de succès de la commande, je suis redirigé vers la page d’accueil et déconnecté.
La solution que j'ai trouvée consiste à inverser l'ordre des blocs de code dans les modifications
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
.En comparant la version corrigée avec le même fichier dans Magento CE 1.9.3.8, j’ai trouvé que les nouveaux blocs permettant de valider l’expiration de la session et l’horodatage du mot de passe sont dans un ordre différent.
Magento CE 1.9.3.8 - Lignes 476-491:
Magento CE 1.7.0.2 - Lignes 414-430:
Cela donne la valeur
$validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
supérieure à$sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
, ce qui signifie que la méthode retourne toujours la valeur false et que la validation échoue.Changer le code dans Magento CE 1.7.0.2 pour qu'il corresponde à la version de Magento CE 1.9.3.8 corrige le problème.
Le code résultant pour Magento CE 1.7.0.2 - Lignes 414-430:
Je suggérerais de créer votre propre fichier de correctif et de l'appliquer directement au fichier principal (c'est ainsi que j'aborde normalement la correction des bogues dans le noyau). Cela faciliterait la restauration si Magento publiait une version 2 du correctif.
la source
useValidateSessionPasswordTimestamp()
retourfalse
. (un changement de ligne dans le même fichier)Nous avons vu une page vierge à / checkout / cart après l’application de SUPEE-10570 et la compilation. Juste pour clarifier les choses: avec le compilateur désactivé, tout se passait bien, avec le compilateur activé, nous ne pouvions voir qu'une page de panier vide lorsque vous vous connectiez sans entrées de journal (même après avoir activé tous les journaux possibles et le mode développeur).
La solution consistait à modifier la fonction
getPasswordTimestamp()
enapp/code/core/Mage/Customer/Helper/Data.php
(bien sûr signifieapp/code/local/Mage/Customer/Helper/Data.php
:!) Et à utiliser à laMage::getSingleton('core/resource')
place deMage::getModel('customer/customer')
ouMage::getSingleton('customer/session')
. Donc, remplacez toute la fonction, par exemple avec ces lignes de code:Après la recompilation, le problème avait disparu. Quelqu'un d'autre avec ce problème?
Explication en allemand ici .
la source
1.7.0.0
Pièce:
PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh
Cette erreur se produit si vous n'avez pas déjà appliqué SUPEE-9652 ou SUPEE-9767
Appliquez ces correctifs pour corriger le problème.
la source
1.7.0.0
PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh
Fichier de correctionapp/code/core/Mage/Core/Model/Session/Abstract/Varien.php
Le correctif pour 1.7.0.0 ajoute seulement une constante:
Cependant, il ajoute l'utilisation de deux nouvelles constantes, notamment celle-ci:
Cela entraîne l'erreur:
Le correctif:
Ajoutez une définition pour cette seconde constante au-dessus ou au-dessous de la première constante ajoutée par ce patch.
Jusqu'ici, je n'ai vu ce problème dans aucun des 1.9. ou les correctifs 1.14.x, car ils définissent la constante correctement.
la source
const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';
en haut du fichier, comme dans la plupart des autres versions de ce correctif.Tout d’abord, vérifiez si la version correcte de SUPEE-6788 ou SUPEE-7405 a déjà été appliquée, sinon retournez la mauvaise version et appliquez la version correcte de SUPEE-6788 / SUPEE-7405.
Puis réessayez d'appliquer SUPEE-10570.
la source
Les fichiers ci-dessous sont mis à jour / ajoutés après l’application du correctif SUPEE - 10570 dans EE.
@DarkCowboy a fourni une liste de fichiers autres que les fichiers EE :
Quelques notes importantes
password_created_at
créé dans la table des attributs du client.Ces fichiers sont utilisés pour la création et la validation. un problème de session se produit lors de la validation de la commande ou de la connexion de l'utilisateur, l'un des fichiers ci-dessus est écrasé dans votre pool local ou un
password_created_at
attribut est créé dans votre table d'attributs client et la valeur appropriée est stockée dans cette table.la source
Ma version de magento est ver. 1.9.1.0.
Nous avons vu une page vierge à / checkout / cart après l’application de SUPEE-10570 et la compilation. Juste pour clarifier les choses: avec le compilateur désactivé, tout se passait bien, avec le compilateur activé, nous ne pouvions voir qu'une page de panier vide lorsque vous vous connectiez sans entrées de journal (même après avoir activé tous les journaux possibles et le mode développeur).
Cause:
la fonction getPasswordTimestamp invoquera deux fois une fois connecté et visité / checkout / cart.
compilateur désactivé à la fois appel travail.
n'activez le compilateur que pour le premier travail d'appel, le second appel a échoué.
quelqu'un peut-il expliquer et donner la bonne solution?
la source
Un problème avec 1.7.0.2 que j'ai remarqué est le suivant:
Ajouter le produit au panier et aller à la caisse
Cliquez sur "S'inscrire"
LE PROBLEME COMMENCE ICI
5. Être automatiquement redirigé vers la PAGE D'ACCUEIL. Vous ne voyez pas la confirmation du numéro de commande. Mais en réalité, la commande est passée et le compte client créé.
la source
J'ai rencontré le même problème, Magento 1.9.3.8 a ajouté cette méthode à la classe Mage_Customer_Helper_Data
Si vous surchargez cette classe dans le dossier Local (ce n’est pas la meilleure pratique), des erreurs peuvent être générées par cette classe.
la source
Ce correctif a endommagé une partie du gestionnaire de hiérarchie du CMS pour les utilisateurs EE.
Ceci est dû à la ligne de correction suivante qui est chargée d'échapper aux noms de magasins / sites Web et de corriger APPSEC-1873/1979/1980.
Le sélecteur de magasin devrait apparaître à gauche, mais le code HTML à droite. Si vous avez vraiment besoin de cette fonctionnalité, vous devez faire appel à la sécurité par opposition à une fonctionnalité qui n’est pas fantastique.
la source
Même erreur exacte que Tyler sur le correctif PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh de Magento 1.9.2.4
la source
Si vous avez un outil de détection de correctif dont vous aurez probablement besoin de modifier la détection
SUPEE-9562
carSUPEE-10570
modifie le même fichier:la source
Le patch a été modifié silencieusement par Magento. Ici montré avec le correctif pour Magento 1.8.1.0-1.9.0.1. Sur le premier téléchargement j'ai obtenu le fichier
Quelques jours plus tard, j'ai le fichier suivant
Diff indique que le fichier précédent contient des fichiers de Magento Enterprise Edition contenant la licence incorrecte "Contrat de licence utilisateur final Magento Enterprise Edition". Cela a été corrigé pour "Open Software License (OSL 3.0)".
la source
Vous pouvez avoir l'erreur suivante
Hunk #3 FAILED at 17
après la ligneCela m'est arrivé sur la version 1.10.0.2EE de Magento. C'est arrivé parce que le correctif SUPEE-6285 n'a pas été appliqué.
la source