CSRF con un'API JSON CORS [duplicato]

Question

CSRF con un'API JSON CORS [duplicato]

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

1

Abbiamo api.example.com che comunica con app.example.com, un'app Android nativa e un'app iOS. Vogliamo consentire ad altre terze parti di comunicare con l'API anche se lo desiderano, e come tale abbiamo Access-Control-Allow-Origin: * header set.

Abbiamo alcune rotte API che non richiedono un'autenticazione precedente come /reset-password e /login .

Ogni altra rotta API richiede un token di autenticazione aggiunto ad esso, ad esempio /important-action?authtoken=abc123 . Non accetta i cookie nelle intestazioni o nel corpo delle richieste. app.example.com salva il token di autenticazione in un cookie per preservare la sessione.

Quello che sto cercando di capire è come evil.com possa sfruttare questa configurazione- Può qualcuno dare qualche esempio di come un attacco potrebbe funzionare o fermarmi mi preoccupa e fammi sapere che CSRF non è un rischio applicabile.

Ho letto altre risposte che si riferiscono a "utilizzo dei cookie", ma non chiariscono cosa si intenda esattamente "usare". Nel nostro caso, stiamo memorizzando authtoken in un cookie e aggiungendolo all'URL della richiesta. L'API ignora tutti i cookie inviati nell'intestazione della richiesta.

api cookies web-application csrf cors

posta Merlin Mason 15.01.2018 - 15:11

fonte

2 risposte

Leggi altre domande sui tag api cookies web-application csrf cors

Come testare se uno strumento non verifica / extendedKeyUsage =? [chiuso] Un ISP monitora la cronologia di navigazione dell'utente senza un mandato di comparizione? [chiuso]

score 1 · Answer 1

La falsificazione di richieste tra siti richiede che l'autore dell'attacco sia in grado di prevedere la richiesta da effettuare. Supponendo che i valori authtoken siano difficili da prevedere (vale a dire, valori casuali di grandi dimensioni, valori hash, ecc.), Sarebbe quindi difficile per un utente malintenzionato forgiare la richiesta.

Tieni presente che se imposti Access-Control-Allow-Origin: * , dovresti assicurarti che nessun endpoint rifletta i token validi o che un utente malintenzionato potrebbe semplicemente leggerli da lì.

score 1 · Answer 2

Ci sono due percorsi possibili che un utente malintenzionato deve esplorare qui:

Si può fare qualcosa con i percorsi che non richiedono l'autenticazione?
Posso in qualche modo mettere le mani sul token?

Vediamo # 1 e i due percorsi. Se il percorso /reset-password invia semplicemente un messaggio di posta elettronica al proprietario dell'account, non è molto utile.

L'altro, /login , è più problematico. Se imposti anche Access-Control-Allow-Credentials: true evil.com potrebbe "forzare" un accesso (con il set di cookie del token). Questo ti apre fino a login CSRF , che può essere qualsiasi cosa, da non un grosso problema a molto cattivo a seconda dell'applicazione . Se non imposti quell'intestazione, i cookie nella risposta verranno scartati e stai andando bene.

Per quanto riguarda il # 2, dipende da se quel token è disponibile in qualsiasi altro posto rispetto al cookie. Il mittente delle richieste cross origin non ha mai il permesso di leggere i cookie, quindi non può leggere il token da lì. Ma forse è incluso da qualche altra parte? Forse la risposta contiene qualche URL con il parametro authtoken in esso?

Non che se il cookie stesso fosse usato come autenticazione quando inviato dal client, questa sarebbe una storia diversa. Allora potresti davvero avere un grosso problema qui.

CSRF a parte, mettere segreti nell'URL è scoraggiato. Dopo tutto, gli URL finiscono in tutti i tipi di log, per non parlare della cronologia del browser. Se non c'è motivo per non farlo, metterei invece il token in un'intestazione. L'intestazione potrebbe effettivamente proteggere anche contro CSRF, dal momento che evil.com non avrebbe il permesso di impostarlo.