La vulnerabilidad de ataque y secuestro de sesión CSRF

Question

A partir de las notas de la versión Alpha 1.8CE:

La tienda web Magento tiene Falsificación de Petición adicional Cross Site (CSRF) protecciones, lo que significa un impostor ya no pueden hacerse pasar por una nueva cliente validado y realizar acciones en nombre del cliente.

y

En versiones anteriores, Magento era vulnerable a una fijación de sesión atacar durante el proceso de registro. Tras iniciar sesión en su cuenta, ID de sesión de un usuario registrado no cambió. Por lo tanto, si un conocimiento atacante tenía de un identificador de sesión no autorizados y si eso usuario se registra con éxito, el atacante fue capaz de hacerse cargo de la nueva cuenta registrada. Ahora, el identificador de sesión cambia después de un éxito registro, haciendo uso no autorizado de una cuenta imposible.

Si esto está en las notas de la versión, y no veo un punto de liberación en las versiones anteriores que tratan esta (estoy mirando en el lugar equivocado?) - a continuación, ¿significa eso que pre-1.8 actual tiendas son potencialmente abierto a estos vectores de ataque

Fuente: http://www.magentocommerce.com/knowledge-base / entrada / ce-18-tarde-release-notes

Answer 1

En resumen, sí. CE 1.7 sigue siendo vulnerable a los ataques específicos porque ninguna versión de seguridad se ha publicado que contiene un parche.

En el caso de este último, un ataque de fijación de sesión, el cambio es una mejora en las prácticas de seguridad que ya se utiliza para Magento estancia en línea con las mejores prácticas de seguridad de la misma. No es algo probable que se publicará a CE 1.7 si lo hacen emitir un parche con las correcciones de CSRF.

La verdadera pregunta es ¿cuáles eran exactamente estas vulnerabilidades CSRF que se fijaron? Sin duda, una cosa buena que no incluyen detalles en las notas de la versión, por lo tanto poner en peligro aún más todas las versiones anteriores, pero sería bueno saber por el bien de parcheo implementaciones de edad.

ACTUALIZACIÓN # 1: Al llegar a Magento para averiguar cuándo será la emisión de parches para las vulnerabilidades anteriores, recibí la siguiente respuesta:

Me Permita un tiempo para investigar más a fondo. No estoy seguro de si hay parches disponibles para esos dos artículos, que estén incluidos en nuestro sistema como mejoras del producto y no como errores. Voy a actualizar cuando llegue a más información.

Voy a publicar más detalles volver aquí como los consigo, y voy a hacer mi mejor esfuerzo para obtener los parches emitidos ya que parece que no hay actualmente ningún parche en existencia.

ACTUALIZACIÓN # 2: Después de ida y vuelta con el equipo de soporte, que era capaz de obtener un parche apropiado para Magento EE 1.12.0.2. No hay parche fue emitida para Magento CE 1.7.0.2, y por lo que el técnico que se veía en su interior para ver me conoce, no hay planes para lanzar un parche oficial para 1.7.x CE vez resolver los problemas sólo en la próxima CE 1.8 versión estable.

En cuanto al archivo de parche EE específica, no puedo publicarlo (o la herramienta de aplicación de parches) aquí directamente ya que la mayor parte, sin duda, en violación de NDA entre Magento y yo personalmente, y la empresa para la que trabajo. El nombre del parche relevante es: "PATCH_SUPEE-1513_EE_1.12.0.2_v1.sh" - Si usted tiene la versión Enterprise Edition o un cliente de usarlo, debe ser capaz de solicitar esta revisión desde el equipo de apoyo Magento junto con una nota acerca las vulnerabilidades CSRF los que se supone va a reparar.

Para los usuarios CE 1.7.0.2, me he tomado la libertad para generar un archivo de revisión (basado en el parche proporcionado por Magento), que incluye sólo los trozos de código que alteran Magento CE archivos de código 1.7.0.2 centrales. De manera normal, que incluye bits irrelevantes de comentarios añadidos y se ajustó el formateo junto con los cambios de código correspondientes. La creación de este necesario alterar manualmente el parche original para aplicarlo a usar el parche proporcionado aplicación de la herramienta, a continuación, utilizando git para generar un parche basado en los cambios aplicados.

El archivo de parche que he creado se puede descargar desde este GIST: https://gist.github.com/davidalger/ 5938568

Para aplicar el parche, primero CD en la raíz de la instalación de Magento y ejecutar el siguiente comando: patch -p1 -i ./Magento_CE_1.7.0.2_v1-CSRF_Patch.diff

El parche EE específica incluida clave formulario de comprobaciones de validación a los controladores específicos de la empresa, las alteraciones de la empresa / default y la empresa / archivos de plantilla de iPhone para incluir claves del formulario en las formas que se utilizan para las acciones del controlador parcheados y adicional funtionality la página índice de caché de adecuadamente cuenta de que pasa claves del formulario de ida y vuelta en las páginas almacenadas en caché.

AVISO: No he probado ya sea el parche proporcionado por EE Magento ni el parche que he subido a la esencia vinculado. El parche proporcionado en la esencia de referencia se proporciona sin la garantía y puede o no puede resolver completamente las vulnerabilidades referencia en las notas de la versión CE 1.8. Como un parche no probado, también hay ninguna garantía de que funcione en su totalidad o en parte. Es decir. utilizar a su propio riesgo, y tomar la debida diligencia a prueba antes de implementara un entorno de producción. Si encuentra problemas con el parche, hágamelo saber y voy a actualizar a él.

Answer 2

No estoy 100% seguro porque no era capaz de reproducir el problema, pero

significa un impostor ya no puede suplantar la identidad de un cliente recién registrado

medios que hasta ahora 'un impostor' podría hacerse pasar por un cliente recién registrado.
Espero que sea sólo 'semántica' pero creo que significa lo que teme que significa.