Creo que será difícil obtener una respuesta definitiva a esta pregunta de por qué es "necesario" un token CSRF en la acción GET de agregar al carrito de Magento. Intentaré interpretar su propósito. De ninguna manera soy un experto en seguridad y esta es mi interpretación de CSRF en este contexto particular.
Contexto
De owasp.org
Cross-Site Request Forgery (CSRF) es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que está autenticado actualmente. Los ataques CSRF apuntan específicamente a solicitudes de cambio de estado, no al robo de datos, ya que el atacante no tiene forma de ver la respuesta a la solicitud falsificada.
Un ejemplo de este ataque es incrustar una imagen oculta en un correo electrónico o en una página web alternativa:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
El servidor web no diferenciará de dónde proviene la solicitud y agregará fielmente el artículo al carrito de ese usuario.
El objetivo de prevenir ataques CSRF es evitar solicitudes de cambio de estado . Agregar un artículo a un carrito se consideraría como un cambio de estado. En general, consideraría que este es un cambio de estado inofensivo en comparación con enviar un pedido, transferir fondos o actualizar una dirección de correo electrónico.
Con respecto a los cambios de estado y los métodos HTTP, RFC 2616 dice lo siguiente:
En particular, la convención ha establecido que los métodos GET y HEAD NO DEBEN tener la importancia de tomar una acción que no sea la recuperación. Estos métodos deben considerarse "seguros".
Magento y CSRF
Magento implementa el mecanismo de prevención CSRF para las áreas de administración y frontend mediante el uso de un token (clave de formulario). Supongo que el objetivo de Magento, como plataforma diseñada para ser construida por otros desarrolladores, es asegurar todas las solicitudes de cambio de estado. La razón es que no tienen idea de lo que los desarrolladores implementadores o las extensiones de terceros pueden exponer inadvertidamente. Es más seguro asegurar todas las solicitudes de cambio de estado que tener algo expuesto por un módulo de terceros y ser un mal PR para la plataforma. En realidad, no sé si todas las solicitudes de cambio de estado están protegidas de los ataques CSRF.
Una cosa a tener en cuenta es que Magento no siempre usa una clave de formulario para proteger las solicitudes de cambio de estado. Por ejemplo, las solicitudes Eliminar del carrito ( /checkout/cart/delete/id/{ID}) y Eliminar dirección del cliente ( /customer/address/delete/id/{ID}) son solicitudes GET que pasan una ID de entidad. El controlador (o modelos) se encarga de garantizar que el usuario esté autorizado para eliminar esos registros de entidad (modificar el estado). Estas son dos instancias donde Magento no sigue RFC 2616 . Para ser justos, para algunos casos de uso puede no ser práctico o necesario hacerlo.
Parece que la verificación de la clave de formulario en el Mage_Checkout_CartController::addActionmétodo se agregó en la versión 1.8. De las notas de la versión, tenemos lo siguiente:
Se resolvieron problemas que podrían haber resultado en falsificación de solicitudes entre sitios (CSRF) en la tienda web.
Lamentablemente, el lenguaje es vago y el "podría haber" me lleva a creer que se debió a la suposición que dije anteriormente: solicitudes seguras de cambio de estado. Puede existir la posibilidad de enviar parámetros adicionales que causen algún tipo de comportamiento no deseado:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
La idea es que al agregar algo al carrito hay algo de código (núcleo o tercero) que se activa durante la adición al carrito, por ejemplo, a través de algún evento enviado.
Parece improbable que tal vulnerabilidad exista de forma inmediata y, de ser así, uno esperaría que Magento hiciera un mejor trabajo al revelar los detalles / riesgos. Un riesgo que pude ver es que Magento almacena ciegamente los parámetros de la solicitud durante la adición al carrito en la product_optionscolumna de la tabla de artículos de pedido de ventas (ver:) info_buyRequest. En teoría, alguien podría engañar a un grupo de usuarios para que agreguen elementos a su carrito con parámetros de consulta extraños y eso se almacenaría en la sales_flat_quote_item_optiontabla y, finalmente, en la sales_flat_order_itemtabla si también pueden hacer que esos usuarios se conviertan. Esto me parece muy poco probable en la mayoría de los casos.
Cuestiones clave del formulario Agregar al carrito
Uno de los grandes problemas que enfrentan las personas con una implementación de FPC y tokens CSRF es que terminan en caché. El primer cliente que calienta el caché genera el token, cuando el segundo cliente obtiene un HIT de caché, ahora se les ha dado una página con el primer token de los usuarios. Al enviar el formulario, los tokens no coincidirán.
Magento Enterprise utiliza marcadores de posición para buscar / reemplazar las claves de formulario en las páginas en caché. Las implementaciones de barniz probablemente usarán un ESI donde sea que se use una clave de formulario.
Me gustaría saber si algunas de las extensiones más populares de "carrito ajax" terminan verificando el token CSRF durante sus solicitudes de agregar al carrito.
La única solicitud de función en la que termino renunciando al token CSRF para la acción de agregar al carrito es permitir la capacidad de crear enlaces de agregar al carrito para usar en correos electrónicos u otros sitios web (redes sociales). A veces, marketing quiere que los usuarios agreguen directamente un artículo al carrito y lo redirijan al carrito o finalicen la compra de inmediato. Esto no se puede hacer fácilmente si se requiere un token CSRF. Solo lo recomendaría si se siente cómodo con el nivel de riesgo y confía en su propio código y el de cualquier tercero.