È sicuro saltare gli assegni CSRF per i non-browser?

Question

È sicuro saltare gli assegni CSRF per i non-browser?

#1 da (2 voti)
#2 da (-1 voti)

1

Ero nel mezzo dell'attuazione di un meccanismo di protezione CSRF per il mio server quando mi sono reso conto che questo attacco interessa davvero solo i browser web. Mi sono chiesto: perché dovrei preoccuparmi di generare / convalidare i token CSRF per i client non-browser?

Non solo la rimozione di tali controlli semplifica l'implementazione dei client REST, ma migliorerebbe anche la scalabilità.

Stavo pensando che tutte le risorse HTML impostino un cookie browserId contenente un valore pseudocasuale crittograficamente strong che identifica il client come browser. Qualsiasi chiamata nell'API REST dovrebbe controllare questo cookie e, se presente, applicare la convalida CSRF. Altrimenti, i controlli verrebbero ignorati.

Il valore del cookie non è importante quanto la sua esistenza. Il valore non è memorizzato o convalidato dal server, ma è utile per legare i token CSRF a un browser specifico (ciò impedisce a un utente malintenzionato di passare il proprio token CSRF a una vittima).

La mia domanda è la seguente:

È possibile distinguere tra i client machine-to-machine (M2M) e human-to-machine (H2M)? Se è così, qual è il modo migliore (è ragionevole l'approccio sopra)?
È sicuro distinguere tra i client M2M e H2M, anche se possibile? O questo ci apre a possibili attacchi in futuro?
Un utente malintenzionato può eliminare i cookie, assumendo che io controlli tutti i sottodomini e utilizzi HTTPS?

rest cookies csrf

posta Gili 27.06.2014 - 06:10

fonte

2 risposte

2

CSRF è per la maggior parte dei moduli e non viene utilizzato affatto per le API REST. Quando l'API REST è implementata con chiavi API e nonce, puoi dire che questi 2 agiscono come protezione contraffatta richiesta cross-site.

Inoltre, quando si progetta l'API REST è solitamente meglio evitare cose come i cookie. Utilizza chiavi API per utente, questo risolverà anche i tuoi problemi di identificazione.

È possibile distinguere tra client machine-to-machine (M2M) e human-to-machine (H2M)? In tal caso, qual è il modo migliore (l'approccio sopra è ragionevole)?

Per un'API di riposo non dovrebbe importare se il client è una macchina o un essere umano. Per identificare gli umani, utilizzare la chiave API per-umana che dovrebbe essere fornita su ogni richiesta. Non esiste una cosa come macchina o umano (cioè non c'è differenza). Tutti sono clienti per l'API.

È sicuro distinguere tra i client M2M e H2M, anche se possibile? O questo ci apre a possibili attacchi in futuro?

Risposta sopra (non dovresti aver bisogno di farlo)

Può un attaccante eliminare i cookie, partendo dal presupposto che io controllo tutti i sottodomini e utilizzare HTTPS?

Risposta sopra (non dovresti usare i cookie per le API REST).

risposta data 27.06.2014 - 09:42

fonte

Leggi altre domande sui tag rest cookies csrf

Richiesta di accesso amministrativo in un'azienda Come ottenere "Politica: X509v3 Qualsiasi politica" in un certificato generato con OpenSSL?

score -1 · Accepted Answer

Rispondere alla mia domanda.

Sì, credo che sia possibile e sicuro distinguere tra browser e non browser utilizzando la presenza di cookie se e solo se:

L'utente malintenzionato non può leggere i valori dei cookie (garantito da SOP )
I valori dei cookie sono obbligatori (impedendo all'utente malintenzionato di effettuare richieste senza di essi).

Propongo di suddividere l'implementazione lato server in due:

Un'API di base per i clienti RESTful.
Un'API del browser che funge da ponte per i browser.

L'API di base non implementa funzionalità specifiche del browser (ad esempio cookie, controlli CSRF).
L'API del browser esegue il mirroring dell'API di base (se necessario, esporta metodi equivalenti, specifici del browser).
- È un'implementazione lato server che esegue controlli di sicurezza specifici del browser e converte funzionalità specifiche del browser nel formato previsto dall'API principale (ad esempio cookie per i valori JSON).
- Invia le richieste all'API di base e converte la risposta in un formato specifico del browser (creando i cookie se necessario).

Un utente malintenzionato non può ignorare i controlli di sicurezza accedendo all'API principale perché ignora i cookie. Senza i cookie, un utente malintenzionato non può eseguire attacchi CSRF.