Acredito que será difícil obter uma resposta definitiva para essa pergunta de por que um token CSRF é "necessário" na ação GET do Magento, adicionada ao carrinho. Farei uma tentativa de interpretar seu objetivo. Não sou de forma alguma um especialista em segurança e essa é minha interpretação do CSRF nesse contexto específico.
Contexto
De owasp.org
A falsificação de solicitação entre sites (CSRF) é um ataque que força um usuário final a executar ações indesejadas em um aplicativo Web no qual eles estão atualmente autenticados. Os ataques CSRF visam especificamente solicitações de alteração de estado, não roubo de dados, pois o invasor não tem como ver a resposta à solicitação forjada.
Um exemplo desse ataque é incorporar uma imagem oculta em um email ou em uma página da Web alternativa:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
O servidor da web não diferenciaria a origem da solicitação e adicionava fielmente o item ao carrinho desse usuário.
O objetivo de impedir ataques de CSRF é impedir solicitações de alteração de estado . Adicionar um item a um carrinho seria considerado uma mudança de estado. Em geral, considero que essa é uma alteração de estado inofensiva em comparação com o envio de um pedido, a transferência de fundos ou a atualização de um endereço de e-mail.
Em relação às alterações de estado e métodos HTTP, o RFC 2616 diz o seguinte:
Em particular, foi estabelecida a convenção de que os métodos GET e HEAD NÃO DEVEM ter o significado de tomar uma ação diferente da recuperação. Esses métodos devem ser considerados "seguros".
Magento e CSRF
O Magento implementa o mecanismo de prevenção de CSRF para áreas administrativas e de front-end usando um token (chave de formulário). Eu assumiria que o objetivo do Magento, como uma plataforma destinada a ser construída por outros desenvolvedores, é garantir todas as solicitações de alteração de estado. O motivo é que eles não têm ideia do que os desenvolvedores de implementação ou extensões de terceiros podem expor inadvertidamente. É mais seguro proteger todas as solicitações de alteração de estado do que ter algo exposto por um módulo de terceiros e ser um mau PR para a plataforma. Na verdade, não sei se todas as solicitações de alteração de estado estão protegidas contra ataques CSRF.
Uma coisa a observar é que o Magento nem sempre usa uma chave de formulário para proteger solicitações de alteração de estado. Por exemplo, as solicitações Excluir do carrinho ( /checkout/cart/delete/id/{ID}) e Excluir endereço do cliente ( /customer/address/delete/id/{ID}) são solicitações GET que passam em um ID da entidade. O controlador (ou modelos) manipula a garantia de que o usuário esteja autorizado a remover esses registros de entidade (modificar estado). Estas são duas instâncias em que o Magento não segue a RFC 2616 . Para ser justo, para alguns casos de uso, pode não ser prático ou necessário fazê-lo.
Parece que a verificação da chave do formulário no Mage_Checkout_CartController::addActionmétodo foi adicionada na versão 1.8. Nas notas de lançamento, temos o seguinte:
Problemas resolvidos que poderiam resultar em falsificação de solicitação entre sites (CSRF) na loja virtual.
Infelizmente, a linguagem é vaga e o "poderia ter" me leva a acreditar que era devido à suposição que afirmei anteriormente: solicitações seguras de mudança de estado. Pode haver uma possibilidade de enviar parâmetros adicionais que causam algum tipo de comportamento não intencional:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
A idéia é que, adicionando algo ao carrinho, há algum código (principal ou de terceiros) que é acionado durante o processo, por exemplo, através de algum evento despachado.
Parece improvável que essa vulnerabilidade exista imediatamente e, se houver, esperamos que o Magento faça um trabalho melhor ao divulgar os detalhes / riscos. Um risco que pude ver é que o Magento armazena cegamente os parâmetros de solicitação durante o add to cart na product_optionscoluna da tabela de itens de pedidos de vendas (consulte info_buyRequest:). Em teoria, alguém poderia induzir um grupo de usuários a adicionar itens ao carrinho com parâmetros de consulta estranhos, que seriam armazenados na sales_flat_quote_item_optiontabela e, eventualmente, na sales_flat_order_itemtabela se eles também conseguirem que esses usuários sejam convertidos. Isso me parece muito improvável na maioria dos casos.
Questões-chave do formulário Adicionar ao carrinho
Um dos grandes problemas que as pessoas enfrentam com a implementação do FPC e os tokens de CSRF é que eles acabam ficando em cache. O primeiro cliente que aquece o cache gera o token, quando o segundo cliente recebe um cache HIT, agora eles recebem uma página com o primeiro token de usuário. Ao enviar o formulário, os tokens não coincidem.
O Magento Enterprise usa espaços reservados para encontrar / substituir as chaves do formulário nas páginas em cache. As implementações de verniz provavelmente usarão um ESI para onde quer que uma chave de formulário seja usada.
Gostaria de saber se algumas das extensões mais populares do "carrinho de ajax" acabam verificando o token CSRF durante suas solicitações de adição ao carrinho.
A única solicitação de recurso em que acabo precedendo o token CSRF para a ação adicionar ao carrinho está permitindo a capacidade de criar links adicionar ao carrinho para uso em e-mails ou outros sites (mídias sociais). Às vezes, o marketing deseja que os usuários adicionem diretamente um item ao carrinho e redirecionem para o carrinho ou finalize a compra imediatamente. Isso não pode ser feito facilmente se um token CSRF for necessário. Eu recomendaria isso apenas se você se sentir confortável com o nível de risco e confiar no seu e em qualquer código de terceiros.