Token CSRF per applicazione di pubblicazione API

Question

Token CSRF per applicazione di pubblicazione API

Naviga le tue risposte

#1 da (2 voti)

0

Attualmente, la mia architettura come segue.

L'API è pubblicata da api.domain.com .
L'applicazione di front end è pubblicata da frontend.domain.com .

Sto prendendo in considerazione due metodi diversi per la protezione CSRF:

Lasciando che il frontend acquisisca un token CSRF effettuando una richiesta a api.domain.com/getCSRF dopo averlo caricato per la prima volta.
Abilita CORS sul mio api.domain.com e consenti solo la richiesta da frontend.domain.com .

Ho trovato un sito Web importante utilizzando il mio primo approccio per ottenere il token CSRF, ma non penso che sia un buon approccio. Quale dei miei metodi è migliore per la protezione CSRF?

api web-application csrf

posta iam batman 04.04.2018 - 08:35

fonte

1 risposta

Leggi altre domande sui tag api web-application csrf

Intolleranza lunga stretta di mano (SSL / TLS) - Riga di comando Esiste una minaccia alla sicurezza dell'uso di "curl https://ipinfo.io/ip" per trovare il nostro IP?

score 2 · Accepted Answer

Avresti bisogno di entrambi:

Solo il n. 1 da solo, senza alcun criterio CORS, non consentirebbe al frontend di leggere le risposte. E se imposti una generosa politica CORS, consentirebbe a tutti gli utenti inclusi in CSRF.
Solo il n. 2 non offrirebbe la protezione CSRF. Non è necessaria l'autorizzazione CORS per inviare normali richieste non verificate, come l'invio di un modulo ordinario. Gli attacchi potrebbero ancora essere montati da qualsiasi dominio. CORS non protegge da CSRF perché non è progettato per.

Insieme funzionano. Il token garantisce che solo le richieste "non contraffatte" sono consentite e il criterio CORS garantisce che solo il frontend possa ottenere le mani sul token.

Devo anche menzionare che in situazioni come questa, con un'API che serve un frontend, la protezione CSRF viene spesso "automaticamente" perché viene utilizzato un token al portatore nell'intestazione auth (al contrario di un cookie). Quindi, se questo è il tuo schema di autenticazione, potresti già essere protetto. Implementare un altro livello di difesa non fa male, però.