Magento ha lanzado un nuevo parche de seguridad para M1 y actualizaciones para M1 y M2.
¿Qué problemas debo tener en cuenta al actualizar o aplicar este parche?
SUPEE-10570, Magento Commerce 1.14.3.8 y Open Source 1.9.3.8 contienen múltiples mejoras de seguridad que ayudan a cerrar la ejecución remota de código (RCE), la creación de scripts entre sitios (XSS) y otros problemas. Estas versiones también incluyen pequeñas correcciones funcionales enumeradas en el Notas de lanzamiento.
MAGENTO 2.2.3, 2.1.12 Y 2.0.18 ACTUALIZACIÓN DE SEGURIDAD
Magento Commerce y Open Source 2.2.3, 2.1.12 y 2.0.18 contienen múltiples mejoras de seguridad que ayudan a cerrar el Cross-Site Scripting (XSS), la ejecución de código remoto de usuario administrador autenticado (RCE) y otras vulnerabilidades. Las versiones incluyen correcciones funcionales adicionales. Para obtener más información sobre las soluciones funcionales, consulte las Notas de la versión de Magento Commerce 2.0.18, 2.1.12, 2.2.3 y Magento Open Source 2.0.18, 2.1.12, 2.2.3.
Respuestas:
Aquí está la lista de archivos modificados por el parche SUPEE-10570:
EDITAR
Finalmente, después de implementar en mi sitio web de productos (CE 1.7.0.2), noté un problema de bloqueo crítico (proceso de pago bloqueado).
El contexto: después de la dirección del paso 1, creo y registro directamente al cliente, debería ver solo el siguiente paso de pago.
El problema: después del supee-10570, el proceso de pago se interrumpe después del paso 1 (en caso de que se cree una cuenta) y el cliente es redirigido a la página de inicio (con el carrito de compras vacío + desconectado) = imposible realizar su pago.
La solución de emergencia: en caso de que encuentre un problema similar con su proceso de pago / sesión del cliente, comente las líneas 414-430 de app / code / core / Mage / Core / Model / Session / Abstract / Varien.php (las agregadas por el parche , vea abajo).
EDITAR (2)
Creo que la siguiente condición siempre devolverá falso (Mage_Core_Model_Session_Abstract_Varien en las líneas 414-419, especialmente las líneas 417 + 418).
VALIDATOR_PASSWORD_CREATE_TIMESTAMP siempre será mayor que VALIDATOR_SESSION_EXPIRE_TIMESTAMP. La marca de tiempo de "vencimiento" de la sesión se redefine en la creación de la cuenta, por lo que inevitablemente es más antigua que la sesión init.
Entonces, por ejemplo, si crea el cliente durante el pago, esto devolverá falso y el cliente simplemente será expulsado (= finalizar el pago, redirigir a la página de inicio y al carrito vacío). Bastante mal.
Informé este problema al equipo de magento. Daré comentarios aquí lo antes posible.
EDITAR (3)
Un nuevo parche es wip (en la página de descarga del parche de magento está escrito "SUPEE-10570 para CE 1.7.0.0 - PARCHE ACTUALIZADO ESPERADO, NO UTILIZAR (0.06 MB)").
EDITAR (4) ~ 1 mes después del problema de bloqueo inicial informado
¡Hola! Espero que todos sean bienes (y espero que no haya mantenido el estado del parche inicial hasta ahora, a menos que los ingresos de su negocio probablemente hayan disminuido seriamente ^^).
Noté la siguiente oración de la página oficial: "Magento ahora está proporcionando un parche actualizado (SUPEE-10570v2) que ya no causa este problema. Sin embargo, tenga en cuenta que este nuevo parche ya no protege contra dos sesiones de bajo riesgo relacionadas con el manejo problemas de seguridad que protegen el parche SUPEE-10570 ". de la página oficial supee-10570.
En la página de lanzamiento finalmente podemos encontrar el archivo v2 (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).
He investigado las modificaciones en detalles. Finalmente, parece que el equipo de magento decidió abandonar una parte de seguridad del parche. Espero que este agujero de seguridad no cause daños graves (es poco crítico según la nota oficial).
Después de revertir v1 + aplicar v2, tenga cuidado de que los siguientes archivos se reviertan como su estado inicial (antes de que se aplicara v1):
PD: obviamente, otros archivos también se modifican, verifique en consecuencia.
fuente
app/etc/applied.patches.list
(no estoy seguro si esto estaba en las notas de la versión desde el principio)
Problemas conocidos
Estos dos problemas conocidos están asociados con el uso de etiquetas HTML dentro del atributo SKU de un producto:
Invalid value in SKU column. HTML tags are not allowed.
HTML tags are not allowed in SKU attribute.
De las notas del parche :
Si el parche no se aplica durante el parche
lib/Zend/Mail/Transport/Sendmail.php
, puede significar que su instalación de Magento fue parcheada previamente con SUPEE-9652v1 en lugar de SUPEE-9652v2. La solución recomendada es revertir el parche SUPEE-9652v1 y aplicar SUPEE-9652v2 antes de aplicar SUPEE-10570.fuente
Tuve el mismo problema que @DarkCowboy después de aplicar el parche a Magento CE 1.7.0.2.
Después de elegir registrarse como un nuevo cliente durante el proceso de pago, al realizar el pedido se crea tanto el pedido como el cliente, pero en lugar de mostrar la página de éxito del pedido, me redirigen a la página de inicio y me desconecto.
La solución que he encontrado es invertir el orden de los bloques de código en los cambios a
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
.Al comparar la versión parcheada con el mismo archivo en Magento CE 1.9.3.8, encontré que los nuevos bloques para validar el vencimiento de la sesión y la marca de tiempo de la contraseña están en un orden diferente.
Magento CE 1.9.3.8 - Líneas 476-491:
Magento CE 1.7.0.2 - Líneas 414-430:
Esto da como resultado el valor de
$validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
ser mayor que$sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
, lo que significa que el método siempre devuelve falso y la validación falla.Cambiar el código en Magento CE 1.7.0.2 para que coincida con la versión en Magento CE 1.9.3.8 soluciona el problema.
El código resultante para Magento CE 1.7.0.2 - Líneas 414-430:
Sugeriría crear su propio archivo de parche y aplicarlo directamente al archivo central (así es como normalmente me acerco a corregir errores en el núcleo). Esto facilitaría la reversión si Magento emite una versión 2 del parche.
fuente
useValidateSessionPasswordTimestamp()
regresarfalse
. (un cambio de línea en el mismo archivo)Vimos una página en blanco en / checkout / cart después de aplicar SUPEE-10570 y compilar. Solo para aclarar: con el compilador desactivado, todo salió bien, con el compilador activado solo pudimos ver una página de carrito en blanco cuando iniciamos sesión sin ninguna entrada de registro (incluso después de activar todos los registros posibles y el modo desarrollador).
La solución fue alterar la función
getPasswordTimestamp()
enapp/code/core/Mage/Customer/Helper/Data.php
(por supuesto, significaapp/code/local/Mage/Customer/Helper/Data.php
:!) Y usar enMage::getSingleton('core/resource')
lugar deMage::getModel('customer/customer')
oMage::getSingleton('customer/session')
. Por lo tanto, reemplace la función completa, por ejemplo, con estas líneas de código:Después de que el problema de compilación desapareció. Alguien más con este problema?
Explicación en alemán aquí .
fuente
1.7.0.0
Parche:
PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh
Este error ocurre si no ha aplicado previamente SUPEE-9652 o SUPEE-9767
Aplique esos parches para corregir el problema.
fuente
1.7.0.0
PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh
Archivo de parcheapp/code/core/Mage/Core/Model/Session/Abstract/Varien.php
El parche para 1.7.0.0 solo agrega una constante:
Sin embargo, agrega el uso de dos constantes nuevas, especialmente esta:
Esto da como resultado el error:
La solución:
Agregue una definición para esta segunda constante arriba o abajo de la primera constante agregada por este parche.
Hasta ahora no he visto este problema en ninguno de los 1.9. o parches 1.14.x, porque definen la constante correctamente.
fuente
const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';
a la parte superior del archivo, como se hace en la mayoría de las otras versiones de este parche.Lo primero que debe verificar, si se le aplicó previamente la versión correcta de SUPEE-6788 o SUPEE-7405, si no revierte la versión incorrecta y luego aplique la versión correcta de SUPEE-6788 / SUPEE-7405.
Luego intente nuevamente aplicar SUPEE-10570.
fuente
Los siguientes archivos se actualizan / agregan después de aplicar el parche SUPEE - 10570 en EE
@DarkCowboy proporcionó una lista de archivos distintos de los archivos EE :
Algunas notas importantes
password_created_at
creado en la tabla de atributos del cliente.Estos archivos anteriores se utilizan para la creación y validación. el problema de la sesión se produce al finalizar la compra o la verificación de inicio de sesión del usuario, cualquiera de los archivos anteriores se sobrescribe en su grupo local o Cualquier
password_created_at
atributo se crea en su tabla de atributos del cliente y el valor adecuado se almacena en esa tabla.fuente
Mi versión magento es ver. 1.9.1.0.
Vimos una página en blanco en / checkout / cart después de aplicar SUPEE-10570 y compilar. Solo para aclarar: con el compilador desactivado, todo salió bien, con el compilador activado solo pudimos ver una página de carrito en blanco cuando iniciamos sesión sin ninguna entrada de registro (incluso después de activar todos los registros posibles y el modo de desarrollador).
Porque:
la función getPasswordTimestamp invocará dos veces cuando inicie sesión y visite / checkout / cart.
desactivado el compilador tanto en el trabajo de invocación.
habilitar el compilador solo el primer trabajo de invocación, la segunda invocación falló.
¿Alguien puede explicar y dar la buena solución?
fuente
Un problema con 1.7.0.2 que he notado es el siguiente:
Agregue el producto al carrito y vaya a pagar
Haga clic en "Registrarse"
EL PROBLEMA COMIENZA AQUÍ
5. Se redirige automáticamente a la PÁGINA DE INICIO. No puede ver la confirmación del número de pedido. Pero en realidad, se realiza un pedido y se crea una cuenta de cliente.
fuente
Me encontré con el mismo problema, Magento 1.9.3.8 agregó este método en la clase Mage_Customer_Helper_Data
Si anula esta clase dentro de la carpeta Local (no es la mejor práctica), es posible que esta clase genere errores.
fuente
Este parche ha roto parte del administrador de jerarquía de CMS para usuarios de EE.
Esto se debe a la siguiente línea de parche que es responsable de escapar de las tiendas / nombres de sitios web y arreglar APPSEC-1873/1979/1980.
Debería mostrar el selector de tienda a la izquierda, pero en su lugar, muestra el html a la derecha. Si realmente necesita esta funcionalidad, debe hacer una llamada de seguridad frente a la funcionalidad que no es excelente.
fuente
El mismo error exacto que Tyler, en Magento 1.9.2.4 Patch PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh
fuente
Si tiene alguna herramienta de detección de parches, probablemente necesite modificar la detección de
SUPEE-9562
porqueSUPEE-10570
modifica el mismo archivo:fuente
El parche fue cambiado por Magento en silencio. Aquí se muestra con el parche para Magento 1.8.1.0-1.9.0.1. En la primera descarga obtuve el archivo
Unos días después recibí el siguiente archivo
Diff muestra que el archivo anterior contiene archivos de Magento Enterprise Edition que contienen la licencia incorrecta "Acuerdo de licencia de usuario final de Magento Enterprise Edition". Esto se ha corregido a "Open Software License (OSL 3.0)".
fuente
Puede obtener el siguiente error
Hunk #3 FAILED at 17
despues de la lineaMe sucedió en la versión Magento 1.10.0.2EE. Sucedió porque el parche SUPEE-6285 no se aplicó.
fuente