Ero nel mezzo dell'attuazione di un meccanismo di protezione CSRF per il mio server quando mi sono reso conto che questo attacco interessa davvero solo i browser web. Mi sono chiesto: perché dovrei preoccuparmi di generare / convalidare i token CSRF per i client non-browser?
Non solo la rimozione di tali controlli semplifica l'implementazione dei client REST, ma migliorerebbe anche la scalabilità.
Stavo pensando che tutte le risorse HTML impostino un cookie browserId
contenente un valore pseudocasuale crittograficamente strong che identifica il client come browser. Qualsiasi chiamata nell'API REST dovrebbe controllare questo cookie e, se presente, applicare la convalida CSRF. Altrimenti, i controlli verrebbero ignorati.
Il valore del cookie non è importante quanto la sua esistenza. Il valore non è memorizzato o convalidato dal server, ma è utile per legare i token CSRF a un browser specifico (ciò impedisce a un utente malintenzionato di passare il proprio token CSRF a una vittima).
La mia domanda è la seguente:
- È possibile distinguere tra i client machine-to-machine (M2M) e human-to-machine (H2M)? Se è così, qual è il modo migliore (è ragionevole l'approccio sopra)?
- È sicuro distinguere tra i client M2M e H2M, anche se possibile? O questo ci apre a possibili attacchi in futuro?
- Un utente malintenzionato può eliminare i cookie, assumendo che io controlli tutti i sottodomini e utilizzi HTTPS?