Devo utilizzare la protezione CSRF sugli endpoint di Rest API?

Non ero originariamente alla ricerca di una risposta autonoma, ma dopo aver letto più mi sono imbattuto in quella che ritengo essere una risposta esaustiva che spiega anche perché alcuni potrebbero essere interessati alla protezione CSRF sugli endpoint REST.

Nessun cookie = Nessuna CSRF

È davvero così semplice. I browser inviano i cookie insieme a tutte le richieste. Gli attacchi CSRF dipendono da questo comportamento. Se non si utilizzano i cookie e non si fa affidamento sui cookie per l'autenticazione, non c'è assolutamente spazio per gli attacchi CSRF e non c'è motivo di inserire la protezione CSRF. Se si dispone di cookie, soprattutto se li si utilizza per l'autenticazione, è necessaria la protezione CSRF. Se tutto quello che vuoi sapere è "Ho bisogno della protezione CSRF per il mio endpoint API?" puoi fermarti qui e partire con la tua risposta. Altrimenti, il diavolo si trova nei dettagli.

h / t a paj28: Sebbene i cookie siano il vettore di attacco principale per gli attacchi CSRF, sei vulnerabile anche se utilizzi l'autenticazione HTTP / Basic. Più in generale, se il browser è in grado di passare automaticamente le credenziali di accesso per la tua app, allora CSRF è importante. Nella mia esperienza, i cookie sono la tecnologia più comune sfruttata per rendere CSRF possibile, ma ci sono alcuni altri metodi di autenticazione che possono causare la stessa vulnerabilità.

REST = Stateless

Se chiedi a qualcuno "cos'è REST" otterrai una varietà di risposte che trattano una varietà di proprietà differenti. Puoi vedere tanto perché qualcuno ha posto questa domanda sullo stack overflow: link

Una proprietà di REST a cui ho sempre fatto affidamento è che è senza stato. L'applicazione stessa ha ovviamente lo stato. Se non puoi memorizzare dati in un database da qualche parte, la tua applicazione sarà piuttosto limitata. In questo caso, tuttavia, l'apolidi ha un significato molto specifico e importante: le applicazioni REST non tracciano lo stato per l'applicazione lato client . Se si stanno utilizzando sessioni, si è (quasi certamente) in grado di tenere traccia dello stato lato client e non si è un'applicazione completa REST. Quindi un'applicazione che utilizza sessioni (specialmente per gli accessi) che vengono tracciate tramite i cookie non è un'applicazione completa REST (IMO) ed è certamente vulnerabile agli attacchi CSRF, anche se in caso contrario sembra un'applicazione REST.

Penso che valga la pena di notare che uno dei motivi per cui l'apolidia lato client è importante per le applicazioni REST è che la capacità degli intermediari di memorizzare le risposte è anche una parte desiderabile del paradigma REST. Finché l'applicazione sta monitorando lo stato lato client, la memorizzazione nella cache non è possibile.

Rest ≠ Cookieless

Per questi motivi, inizialmente pensavo che un'applicazione REST pienamente compatibile non avrebbe mai avuto bisogno di sessioni, non avrebbe mai avuto bisogno di cookie e quindi non avrebbe mai avuto bisogno della sicurezza CSRF. Tuttavia, esiste almeno un caso d'uso che può preferire i cookie in ogni caso: accessi persistenti.

Considera una tipica applicazione web lato client (in questo caso browser, non mobile). Si inizia accedendo, che utilizza un'API REST per convalidare le credenziali dell'utente e in cambio viene fornito un token per autorizzare richieste future. Per le applicazioni a pagina singola, è sufficiente mantenere il token in memoria, ma in questo modo verrà effettivamente registrato l'utente se chiude la pagina. Di conseguenza, sarebbe opportuno mantenere lo stato da qualche parte che può durare più a lungo di una singola sessione del browser. L'archiviazione locale è un'opzione, ma è anche vulnerabile agli attacchi XSS: un attacco XSS di successo può portare l'utente malintenzionato ad afferrare i token di accesso e inviarli all'autore dell'attacco per essere utilizzato a sua discrezione.

Per questo motivo, ho visto alcuni suggerire di utilizzare i cookie per memorizzare i token di accesso. Con un cookie è possibile impostare il flag solo http, che impedisce all'applicazione di leggere il cookie dopo che è stato impostato. Di conseguenza, in caso di un attacco XSS, l'utente malintenzionato può comunque effettuare chiamate a tuo nome, ma non possono rinunciare al token di autorizzazione tutti insieme. Questo utilizzo di cookie non viola direttamente il requisito di apolidia di REST perché il server non sta ancora monitorando lo stato lato client. È solo alla ricerca di credenziali di autenticazione in un cookie, piuttosto che nell'intestazione.

Ne parlo perché è potenzialmente un motivo legittimo per utilizzare i cookie con un'API REST, anche se è ovviamente fino a una determinata applicazione per bilanciare i vari problemi di sicurezza e usabilità. Cercherò personalmente di evitare l'uso di cookie con le API REST, ma potrebbero comunque esserci motivi per utilizzarli comunque. In entrambi i casi, la risposta generale è semplice: se si utilizzano i cookie (o altri metodi di autenticazione che il browser può fare automaticamente), allora è necessaria la protezione CSRF. Se non stai usando i cookie, allora non lo fai.

"there is no way for a browser to automatically provide authentication credentials even if it is somehow tricked into visiting the API endpoint"

Fai attenzione alle reti private usando l'autenticazione integrata di Windows / Kerberos. In questo scenario, il brower fornirà automaticamente credenziali (kerberos o token NTLM) se configurato per farlo.

Quindi, credo che in questo caso sia richiesto CSRF.

Rest API endpoints have a very important difference from other requests: they are specifically stateless, and should never accept/use data from either a cookie or session.

Se è così che si definisce "API REST", non è possibile creare CSRF. CSRF, chiamato anche "session riding" [ citazione ], ovviamente non funzionerà se non ci sono sessioni per "cavalcare".