Mentre posso vedere alcuni dei sovraccarichi della protezione CSRF (generazione di token, convalida di token, lavoro extra da implementare), non vedo alcun motivo per cui vorresti mai non voglio .
C'è mai un caso in cui la protezione CSRF è qualcosa che NON dovrebbe essere usato? Non sto parlando di casi in cui non è necessario, ad esempio azioni senza effetti collaterali, ma casi in cui il suo utilizzo è in realtà una cattiva idea.
In realtà, potrebbe esserci un caso d'uso, ma è un po 'forzato e dipende da come viene generato il token CSRF.
In molti casi, il token CSRF è solo un token casuale che è legato al sessione e non è correlato a nessun livello di autenticazione. Quando il cliente richiede una pagina contenente un modulo web, il modulo ha il token incorporato in esso come un campo nascosto. Quando il client invia i dati del modulo, il server verifica il il token è uguale a quello inviato e può essere abbastanza sicuro della risposta dallo stesso client che ha inviato il modulo a. Tutto bene.
Tuttavia, questo flusso di lavoro è meno conveniente nel contesto di un'API web in cui il il contatto iniziale con il server proviene da un cliente che sta pubblicando alcuni dati (spesso sotto forma di alcuni JSON). In questo caso, il server non è stato in grado di inviare a gettone. Normalmente, una web api avrebbe qualche altro tipo di verifica - per Ad esempio, si utilizza JWT, l'app client effettuerà una connessione iniziale a server in cui esegue alcune autenticazioni e ottiene un JWT che utilizza in tutto future chiamate API.
Spesso, questo non è un problema in quanto si avrà una separazione delle preoccupazioni. Ci sarà essere un insieme di URL utilizzati da un client Web che segue la normale richiesta di un modulo quindi invia il flusso di lavoro dei dati e un URL API separato che utilizza qualcosa di simile JWT. Non è necessario un token CSRF.
Il problema può essere quando si hanno diversi requisiti simili per entrambi. Tu veramente non voglio dover mantenere due gruppi separati di gestori e preferirei farlo basta avere quello che può essere utilizzato da un client web tradizionale e anche come un Client API. In entrambi i casi, viene utilizzato un token, ma sono di natura diversa.
Ho detto che questo è stato inventato. In realtà, ho incontrato solo questo tipo di problema durante lo sviluppo di un nuovo servizio in cui volevo un'interfaccia client web come così come l'API solo per scopi di sviluppo / debug. In questo caso, cosa io ho fatto è avere alcuni javascript nella versione basata su browser che fa un autenticazione iniziale con il server e ottiene il JWT che copia nel file modulo web come solo un altro valore. Tuttavia, posso immaginare una situazione in cui tu desidera supportare un'interfaccia "tradizionale" basata sul browser Web generale e a applicazione che utilizza HTTP / HTTPS per la comunicazione tramite un'API.
In una certa misura, questa è davvero solo semantica. Il concetto base di fornire a il token nei moduli Web per la protezione da CSRF non varia in modo diverso da un'API che sta usando un token per scopi authn / authz. L'unica vera differenza è che il token CSRF di solito non implica nulla di più del fatto che il la risposta proviene dallo stesso cliente a cui sono stati inviati i dati iniziali del modulo durante l'API token sta facendo affermazioni sull'utente reale. Tecnicamente, non c'è motivo per cui quest'ultimo non può essere utilizzato per il primo, a condizione che il server sia in grado di gestire quello. Il primo non può essere usato per quest'ultimo.
Non riesco a pensare a un caso in cui non dovrebbe essere usato CSRF, a parte i casi non necessari. Quando dici che non dovrebbe essere usato stai parlando di un caso in cui questo fondamentalmente rompe qualcosa? Un token CSRF non dovrebbe rompere nulla, quindi non posso pensare a un caso del genere
Leggi altre domande sui tag web-application appsec csrf