Ataque CSRF y vulnerabilidad de secuestro de sesión

De las notas de la versión 1.8CE Alpha:

La tienda web de Magento tiene protecciones adicionales de falsificación de solicitudes de sitios cruzados (CSRF), lo que significa que un impostor ya no puede hacerse pasar por un cliente recién registrado y realizar acciones en nombre del cliente.

y:

En versiones anteriores, Magento era vulnerable a un ataque de fijación de sesión durante el proceso de registro. Después de iniciar sesión en su cuenta, el ID de sesión de un usuario registrado no cambió. Por lo tanto, si un atacante tenía conocimiento de una ID de sesión no autorizada y si ese usuario se registra con éxito, el atacante pudo hacerse cargo de la cuenta recién registrada. Ahora, el ID de la sesión cambia después de un registro exitoso, haciendo imposible el uso no autorizado de una cuenta.

Si esto está en las notas de la versión, y no veo un lanzamiento puntual en versiones anteriores que aborden esto (¿estoy buscando en el lugar equivocado?), Entonces eso significa que las tiendas actuales anteriores a la 1.8 están potencialmente abiertas a este ataque vectores ?

Fuente: http://www.magentocommerce.com/knowledge-base/entry/ce-18-later-release-notes

En resumen, si. CE 1.7 sigue siendo vulnerable a esos ataques específicos porque no se ha emitido ninguna versión de seguridad que contenga un parche.

En el caso de este último, un ataque de fijación de sesión, el cambio es una actualización de las prácticas de seguridad que Magento ya usaba para mantenerse en línea con las mejores prácticas de seguridad actuales. No es probable que se emita algo a CE 1.7 si emiten un parche con las correcciones CSRF.

La verdadera pregunta es, ¿cuáles fueron exactamente estas vulnerabilidades CSRF que fueron reparadas? Sin duda, es bueno que no hayan incluido datos específicos en las notas de la versión, lo que pone en peligro aún más todas las versiones anteriores, pero sería bueno saberlo en aras de parchear implementaciones antiguas.

ACTUALIZACIÓN # 1: Al comunicarme con Magento para saber cuándo emitirán parches para las vulnerabilidades anteriores, recibí la siguiente respuesta:

Permíteme algo de tiempo para investigar esto más a fondo. No estoy seguro de si hay parches disponibles para esos dos elementos, ya que se enumeran en nuestro sistema como mejoras del producto y no como errores. Te actualizaré cuando tenga más información.

Publicaré más detalles aquí a medida que los reciba, y haré todo lo posible para que se publiquen los parches, ya que parece que actualmente no existen parches.

ACTUALIZACIÓN # 2: Después de ir y venir con el equipo de soporte, pude obtener un parche adecuado para Magento EE 1.12.0.2. No se emitió ningún parche para Magento CE 1.7.0.2, y hasta donde el técnico que lo investigó internamente para mí sabe, no hay planes para lanzar un parche oficial para CE 1.7.x, en lugar de resolver los problemas solo en el próximo CE 1.8 Lanzamiento estable.

En cuanto al archivo de parche específico de EE, no puedo publicarlo (o la herramienta de aplicación de parches) aquí directamente, ya que sin duda sería una 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 tiene la Edición Enterprise o un cliente que la usa, debe poder solicitar este parche al equipo de soporte de Magento junto con una nota sobre las vulnerabilidades CSRF que se supone que debe corregir.

Para los usuarios de CE 1.7.0.2, me he tomado la libertad de generar un archivo de parche (basado en el parche proporcionado por Magento) que incluye solo los trozos de código que alteran los archivos de código central de Magento CE 1.7.0.2. De manera normal, incluye bits irrelevantes de comentarios agregados y formato ajustado junto con los cambios de código relevantes. Crear esto requería modificar manualmente el parche original para aplicarlo usando la herramienta de aplicación de parches provista, luego usar git para generar un parche basado en los cambios aplicados.

El archivo de parche que he creado se puede descargar de esta esencia: https://gist.github.com/davidalger/5938568

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

El parche específico de EE incluyó comprobaciones de validación de clave de formulario para controladores específicos de Enterprise, alteraciones a los archivos de plantilla de empresa / predeterminado y de empresa / iphone para incluir claves de formulario en los formularios que se utilizan para las acciones de controlador parcheadas, y la funcionalidad adicional de caché de página completa para tener en cuenta adecuadamente pasar claves de formulario de ida y vuelta en páginas almacenadas

DESCARGO DE RESPONSABILIDAD: NO HE PROBADO ni el parche EE proporcionado por Magento ni el parche que he subido a la esencia vinculada. El parche proporcionado en la lista de referencia se proporciona SIN GARANTÍA y puede o no resolver completamente las vulnerabilidades mencionadas en las notas de la versión CE 1.8. Como parche no probado, tampoco hay garantía de que funcione en su totalidad o en parte. Es decir, utilizar bajo su propio riesgo y tomar la debida diligencia para probar antes de implementar en un entorno de producción. Si encuentra problemas con el parche, avíseme y lo actualizaré.

No estoy 100% seguro porque no pude reproducir el problema, pero

lo que significa que un impostor ya no puede hacerse pasar por un cliente recién registrado

significa que hasta ahora "un impostor" podría hacerse pasar por un cliente recién registrado.
Espero que sea solo "semántica", pero creo que significa lo que temes.