Credo che sarà difficile trovare una risposta definitiva a questa domanda sul perché un token CSRF è "necessario" nell'azione GET da aggiungere al carrello di Magento. Proverò a interpretare il suo scopo. Non sono affatto un esperto di sicurezza e questa è la mia interpretazione del CSRF in questo particolare contesto.
Contesto
Da owasp.org
Cross-Site Request Forgery (CSRF) è un attacco che costringe un utente finale ad eseguire azioni indesiderate su un'applicazione Web in cui è attualmente autenticato. Gli attacchi CSRF prendono di mira specificamente le richieste di cambiamento di stato, non il furto di dati, poiché l'attaccante non ha modo di vedere la risposta alla richiesta falsificata.
Un esempio di questo attacco è l'incorporamento di un'immagine nascosta in un'e-mail o in una pagina Web alternativa:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
Il web server non dovrebbe differenziare la provenienza della richiesta e aggiungerebbe fedelmente l'articolo al carrello dell'utente.
L'obiettivo di prevenire gli attacchi CSRF è prevenire le richieste di cambiamento di stato . L'aggiunta di un articolo a un carrello verrebbe considerato come un cambio di stato. In generale, considererei questo un cambiamento di stato innocuo rispetto all'invio di un ordine, al trasferimento di fondi o all'aggiornamento di un indirizzo e-mail.
Per quanto riguarda i cambiamenti di stato e i metodi HTTP, RFC 2616 afferma quanto segue:
In particolare, è stata stabilita la convenzione che i metodi GET e HEAD NON DOVREBBERO avere il significato di intraprendere un'azione diversa dal recupero. Questi metodi dovrebbero essere considerati "sicuri".
Magento e CSRF
Magento implementa il meccanismo di prevenzione CSRF sia per le aree di amministrazione che di frontend utilizzando un token (chiave del modulo). Suppongo che l'obiettivo di Magento, in quanto piattaforma pensata per essere costruita da altri sviluppatori, è quello di proteggere tutte le richieste di cambiamento di stato. Il motivo è che non hanno idea di ciò che gli sviluppatori implementatori o le estensioni di terze parti potrebbero esporre inavvertitamente. È più sicuro proteggere tutte le richieste di modifica dello stato piuttosto che avere qualcosa esposto da un modulo di terze parti ed essere un cattivo PR per la piattaforma. In realtà non so se tutte le richieste di modifica dello stato siano protette dagli attacchi CSRF.
Una cosa da notare è che Magento non utilizza sempre una chiave del modulo per proteggere le richieste di modifica dello stato. Ad esempio, le richieste Elimina dal carrello ( /checkout/cart/delete/id/{ID}) e Elimina indirizzo cliente ( /customer/address/delete/id/{ID}) sono entrambe richieste GET che passano in un ID entità. Il controller (o i modelli) si occupano quindi di garantire che l'utente sia autorizzato a rimuovere tali record di entità (modifica stato). Questi sono due casi in cui Magento non segue RFC 2616 . Ad essere onesti, per alcuni casi d'uso potrebbe non essere pratico o necessario farlo.
Sembra che il controllo della chiave del modulo nel Mage_Checkout_CartController::addActionmetodo sia stato aggiunto nella versione 1.8. Dalle note di rilascio abbiamo le seguenti indicazioni:
Risolti i problemi che avrebbero potuto comportare la falsificazione di richieste tra siti (CSRF) nel Web store.
Sfortunatamente la lingua è vaga e il "possibile" mi porta a credere che fosse dovuto al presupposto che ho affermato in precedenza: richieste di cambiamento di stato sicuro. Potrebbe esserci la possibilità di inviare parametri aggiuntivi che causano una sorta di comportamento indesiderato:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
L'idea è che aggiungendo qualcosa al carrello ci sia un po 'di codice (core o di terze parti) che viene attivato durante l'aggiunta al carrello, ad esempio tramite un evento inviato.
Sembra improbabile che una tale vulnerabilità esista fuori dagli schemi e, se lo fa, si spera che Magento possa fare un lavoro migliore nel rivelare i dettagli / i rischi. Un rischio che ho potuto vedere è che Magento memorizza ciecamente i parametri della richiesta durante l'aggiunta al carrello nella product_optionscolonna della tabella degli articoli dell'ordine di vendita (vedi:) info_buyRequest. In teoria qualcuno potrebbe indurre un gruppo di utenti ad aggiungere elementi al proprio carrello con strani parametri di query e che verrebbero archiviati nella sales_flat_quote_item_optiontabella e infine nella sales_flat_order_itemtabella se fossero anche in grado di ottenere la conversione di quegli utenti. Questo mi sembra molto improbabile nella maggior parte dei casi.
Aggiungi al carrello Problemi chiave del modulo
Uno dei grandi problemi che le persone incontrano con un'implementazione FPC e token CSRF è che finiscono per essere memorizzati nella cache. Il primo client che riscalda la cache genera il token, quando il secondo client ottiene un HIT della cache, ora gli è stata assegnata una pagina con il primo token degli utenti. Quando si invia il modulo i token non corrispondono.
Magento Enterprise utilizza segnaposto per trovare / sostituire le chiavi del modulo nelle pagine memorizzate nella cache. Le implementazioni di vernice useranno probabilmente un ESI ovunque venga utilizzata una chiave del modulo.
Sarei curioso di sapere se alcune delle estensioni "ajax cart" più popolari finiscono per controllare il token CSRF durante le loro richieste di aggiunta al carrello.
L'unica richiesta di funzionalità in cui finisco per rinunciare al token CSRF per l'azione Aggiungi al carrello è consentire la possibilità di creare collegamenti Aggiungi al carrello da utilizzare in e-mail o altri siti Web (social media). A volte il marketing vuole che gli utenti aggiungano direttamente un articolo al carrello e reindirizzino immediatamente al carrello o alla cassa. Questo non può essere fatto facilmente se è richiesto un token CSRF. Lo consiglierei solo se ti senti a tuo agio con il livello di rischio e ti fidi del tuo codice di terze parti.