CSRF è obbligatorio per un'applicazione REST di backend che utilizza solo JSON?

numerose risorse sostengono che (source1) (source2)CSRF è obbligatorio per un'applicazione REST di backend che utilizza solo JSON?

Per le risorse esposte dai servizi web RESTful, è importante assicurarsi che qualsiasi PUT, POST, e DELETE richiesta viene protetto dal Cross Site Request Forgery.

CSRF è obbligatoria per tutte le applicazioni con un minimo di preoccupazione per la sicurezza web

Tuttavia the Spring Security docs dicono:

uso protezione CSRF per qualsiasi richiesta che possa essere elaborato da un browser utenti normali. Se si sta creando solo un servizio utilizzato da client non browser, è probabile che si desideri disabilitare la protezione CSRF.

Quindi, è corretto disabilitare CSRF per un'applicazione che?

espone solo un'API REST
consuma solo JSON (controlli le richieste di intestazione Content-Type)

fonte

2015-12-01 Adam Siemion

bene, cosa fa l'applicazione? se il json accetta è qualcosa come "{" command ":" nuke the universe "}', potresti voler avere un BIT di WEE di protezione su di esso per assicurarti che il piccolo scriptkiddy accanto non possa emettere quel comando ... –

Il fatto che non serva HTML e consumi solo JSON non è ciò che conta. Ciò che conta è: le richieste destinate al servizio REST dovrebbero provenire dai client browser o meno. –

@JBNizet Vengono da Javascript in esecuzione nei browser, ma non dall'invio di moduli HTML poiché è impossibile inviare un modulo con tipo di contenuto application/json. –

Dipende dal cliente del vostro API. Gli attacchi CSRF si basano sul fatto che il client invia automaticamente i cookie (autorizzazione) dell'URL richiesto con la richiesta HTTP. Se il tuo cliente non lo fa (di solito i browser lo fanno automaticamente), dovresti essere OK.

Il motivo è: Se il tuo utente API non è autenticato/autorizzato nella tua applicazione tramite cookie (che vengono automaticamente memorizzati dal browser), l'utente malintenzionato non può utilizzare altre pagine Web per eseguire un attacco CSRF di successo (invia richiesta HTTP da altra pagina con i cookie della tua API dal browser).

In altre parole, non posso immaginare che tu abbia un client API scritto in modo che possa inviare richieste alla tua API, memorizzare i cookie (la tua autenticazione) e anche in qualche modo mostrarti del contenuto che "stupido" l'utente interagisce - invia richieste alla tua API con i cookie (la tua autenticazione) da precedenti richieste API.

fonte

2015-12-01 20:18:01 d1x

Beh ... importa quando si tratta di sfruttare.L'unico modo per inviare una richiesta di applicazione/json in un browser è l'utilizzo di Javascript, ma la stessa politica di origine impedisce a JS di effettuare una richiesta a un host di origine diversa e passa a utilizzare CORS, CORS invia una richiesta di preflight al mio REST e poi il mio REST può rifiutarlo. –

Intendi tipo di contenuto? Bene parzialmente ma generalmente non vedo come si possa fare un attacco CSRF di successo senza client che agisce come browser - in altre parole che memorizza i cookie (che ti autorizzano) e può fare richieste alla tua API e anche a qualsiasi pagina web malevola (che ri-accetta i cookie delle richieste API) – d1x

I cookie non devono essere coinvolti negli attacchi CSRF. Ho effettuato l'accesso a mybank.com utilizzando l'autenticazione HTTP di base (supponiamo), accedo a evil.com dove c'è

Abbastanza facile da spiegare questo:

CSRF token viene generato in base Http Session. Se la tua API è in possesso della sessione http, vuoi correttamente proteggerla con il token CSRF, BUT la maggior parte dei servizi REST sono progettati per essere apolidi, in tal caso non puoi/non devi/non utilizzerei il token CSRF.

fonte

2015-12-01 20:20:52 Jaiwo99

Non sono sicuro se questo è corretto. Come si desidera attaccare la sessione HTTP come API (ad esempio con token bearer) senza browser (o client che invia automaticamente i cookie)? – d1x

CSRF è obbligatorio per un'applicazione REST di backend che utilizza solo JSON?

risposta

Problemi correlati