CSRF nell'architettura dei microservizi

TL; DR: gestisce CSRF nello stesso punto (gateway o servizio dietro di esso) dove si gestisce l'autenticazione. O non utilizzare i cookie per i token di autenticazione.

La versione lunga

In un progetto senza stato l'approccio più comune per la protezione CSRF è doppio cookie di invio . Anche se il server non ha uno stato o una sessione, sul lato client è presente una sessione di sicurezza. È molto importante implementare il doppio cookie di invio in modo che sia legato a questa sessione di sicurezza e non farlo ingenuamente . Consulta questo articolo per ulteriori dettagli.

Un approccio all'archiviazione consiste nell'includere il token CSRF all'interno del cookie di autenticazione e creare un cookie di autenticazione httpOnly. In questo modo un utente malintenzionato su un sottodominio compromesso sarà costretto a sovrascrivere sia il cookie di autenticazione che il token CSRF che non può eseguire poiché non può simulare i cookie di autenticazione. Anche se ha un cookie di autenticazione valido (il suo, ad esempio), questo cambierà l'utente autenticato e in questo modo riuscirà a sconfiggere lo scopo di CSRF. Inoltre, sovrascrivere il cookie non è sufficiente per sconfiggere CSRF poiché l'applicazione client non sta leggendo il token CSRF dal cookie stesso (è httpOnly), ma viene assegnato un token CSRF su un'autenticazione corretta.

I passaggi necessari per implementare questo approccio possono essere trovati qui . Anche se la risposta su questo link riguarda JWT, lo stesso approccio è valido per qualsiasi formato di token utilizzato per l'autenticazione.

Nell'architettura dei microservizi stateless l'approccio migliore consiste nel gestire CSRF nello stesso punto in cui si gestisce l'autenticazione sia sul gateway o su qualche altro servizio dietro di esso poiché è necessario gestire l'autenticazione su ogni richiesta e il token CSRF è (se si attuare il mio consiglio sopra) legato all'autenticazione. Qualsiasi altra opzione opzionale complicherà ulteriormente le cose e forse interromperà del tutto la protezione CSRF. Ad esempio:

1. Si sta elaborando l'autenticazione su un gateway o su un altro servizio ma non si può cambiare il modo in cui viene eseguita l'autenticazione e quindi non è possibile aggiungere la protezione CSRF in quel luogo. In questo caso sarà necessario estrarre il token CSRF dal token auth e inoltrarlo al servizio di destinazione insieme all'intestazione CSRF per l'elaborazione. Questo implica che dovrai fare la protezione CSRF in ogni servizio che non è una buona cosa. Non è possibile garantire che ciascun servizio esegua questo controllo. Inoltre, dovrai preoccuparti della comunicazione tra servizi. La disattivazione della protezione CSRF con una presenza di una determinata intestazione è possibile ma potrebbe costituire un rischio per la sicurezza di per sé.
2. Non si sta eseguendo l'autenticazione su un gateway o non si dispone di un gateway, le credenziali del client (token / cookie di autenticazione) vengono inoltrate a tutti i servizi in catena di richiesta e ogni servizio deve gestire la propria autenticazione / protezione CSRF. Come sopra, non è possibile garantire che ciascun servizio lo farà, ma l'approccio per la gestione di CSRF è descritto sopra.

Un altro approccio per gestire CSRF è di non avere cookie per i token di autenticazione e utilizzare invece le intestazioni per passare i token di autenticazione in giro. In caso di una vulnerabilità XSS, ciò renderà più semplice il furto del token di autenticazione. Un articolo su questo dilemma può essere trovato qui .

CSRF è solo un problema con i browser (e le app che incorporano un browser come una visualizzazione Web in un'app mobile), quindi non è necessario implementare la protezione per le comunicazioni macchina-macchina, in quanto utilizzano una libreria client HTTP e URL codificati, quindi non c'è modo di renderli "sfogliare" un endpoint vulnerabile a CSRF come è possibile con un normale browser (con un tag img per esempio).

Per quanto riguarda i normali clienti, anche se il tuo micro servizio è raggiungibile dall'esterno, non dovrebbe essere un problema in quanto il suo sistema di autenticazione dovrebbe consentire solo client autorizzati (altri microservizi, app mobili, ecc.) e anche se un il cliente è indotto ad accedere ai suoi endpoint API, non dovrebbe avere le credenziali corrette per autenticarsi (a meno che le chiavi oi cookie API rivolti al cliente possano in qualche modo funzionare per i micro servizi interni, che è una cattiva idea e dovresti prevenirli).