Domanda Gli attacchi CSRF si applicano alle API?


In particolare, sto scrivendo un'API di Django RESTful per eseguire il backup di un'applicazione iOS e continuo a utilizzare le protezioni CSRF di Django ogni volta che scrivo metodi per gestire le richieste POST.

La mia comprensione è che i cookie gestiti da iOS non sono condivisi dalle applicazioni, il che significa che i miei cookie di sessione sono sicuri e che nessun'altra applicazione può utilizzarli. È vero? In tal caso, posso semplicemente contrassegnare tutte le mie funzioni API come esenti da CSRF?


44
2018-05-24 16:14


origine


risposte:


Questo non è lo scopo di CSRF. CSRF serve a prevenire la pubblicazione diretta di dati sul tuo sito. In altre parole, il cliente deve effettivamente pubblicare un messaggio approvato sentiero, cioè visualizza la pagina del modulo, compila, invia i dati.

Un'API praticamente preclude CSRF, perché il suo scopo è generalmente quello di permettere Enti di terze parti per accedere e manipolare i dati sul tuo sito (il "cross-site" in CSRF). Quindi, sì, penso che di norma ogni view API dovrebbe essere esente da CSRF. Tuttavia, tu dovrebbero segui comunque le best practice e proteggi ogni endpoint dell'API che effettivamente apporta una modifica con una qualche forma di autenticazione, come OAuth.


45
2018-05-24 16:33



Gli attacchi CSRF si basano sul fatto che i cookie vengano inviati implicitamente con tutte le richieste a un determinato dominio. Se i tuoi endpoint API non consentono l'autenticazione basata su cookie, dovresti essere bravo.

Anche se utilizzi l'autenticazione basata su cookie, i tuoi cookie sono sicuri perché Le app iOS non condividono i cookie. Tuttavia, a meno che tu non blocchi intenzionalmente i browser web richiedendo un'intestazione user-agent insolita, un'altra parte potrebbe creare un'app basata su browser che utilizza la tua API e tale app sarebbe vulnerabile agli attacchi CSRF se la tua API supporta l'autenticazione basata su cookie e non Applicare la protezione CSRF.


37
2018-01-07 04:03



Si applicano anche se stai utilizzando la tua API per supportare un sito web.

In questo caso hai ancora bisogno di una qualche forma di protezione CSRF per impedire a qualcuno che incorpora richieste in altri siti di avere effetti drive-by sull'account di un utente autenticato.

Chrome sembra negare le richieste POST di origine incrociata per impostazione predefinita (altri browser potrebbero non essere così rigidi), ma consente alle richieste GET di incrociarsi in modo che sia necessario accertarsi che le richieste GET nella propria API non abbiano effetti collaterali.


15
2018-05-22 22:16



Questa risposta attualmente accettata (maggio 2012) è per lo più corretta, tranne quando si utilizza l'autenticazione basata su sessione. Vale anche la pena ricordare il ruolo di CORS.

Lo scenario semplice è che tu visiti foo.com e il sito Web esegue Javascript per creare una richiesta DELETE basata su AJAX api.com/users/123 e finisce per cancellare l'utente per tuo conto. Ora questo non è sempre possibile a causa di CORS: i browser prevengono foo.com dal fare una richiesta a api.com salvo che api.com whitelist esplicitamente foo.com. Ciò presuppone anche che si stia utilizzando l'autenticazione basata su sessione per le API in contrapposizione all'autenticazione basata su token. Nell'autenticazione basata sulla sessione, qualsiasi utente a cui è stato effettuato l'accesso api.com può eseguire richieste mentre rimangono loggati. Se si dispone dell'autenticazione basata su token (ogni richiesta deve essere realizzata con un HTTP Authorizationintestazione contenente il token auth) quindi si è al sicuro. L'autenticazione basata sulla sessione invia implicitamente il token di autenticazione tramite i cookie.

Uno scenario leggermente peggiore è se uno dei tuoi domini CORS è compromesso - diciamo che hai un modulo che non disinfetta Javascript e un utente riesce a iniettare JS sul tuo sito attraverso quel modulo. Se si utilizza l'autenticazione basata sulla sessione, un utente autenticato che visita la pagina vedrà l'esecuzione di Javascript e farà una richiesta API. Questo potrebbe essere disastroso e una possibilità molto reale se si utilizza l'autenticazione basata su sessione per la propria API.


9
2017-12-01 10:49



Secondo Documentazione DRF, Le API sono vulnerabili all'attacco CSRF fino a quando il server utilizza la sessione autenticata (invece di chiedere ogni volta la password)

La soluzione è

  1. Assicurarsi che le operazioni HTTP "sicure", come ad esempio GET, HEAD e OPTIONS non può essere utilizzato per alterare qualsiasi stato lato server.
  2. Assicurarsi che qualsiasi operazione HTTP 'non sicura', come POST, PUT, PATCH e DELETE, richiede sempre un token CSRF valido.

1
2018-01-13 06:40