È sicuro utilizzare più volte un token CSRF?

Question

È sicuro utilizzare più volte un token CSRF?

#1 da (1 voti)

3

Sono nuovo del problema CSRF e sto studiando come implementare la protezione CSRF in applicazioni popolari come Facebook, Instagram, ecc. Ora sto studiando come viene utilizzata la protezione CSRF nell'implementazione di OAuth.

Alcuni servizi (Instagram, Todoist) consentono di passare un argomento aggiuntivo quando viene richiesto un URL di autorizzazione OAuth. Questo argomento è descritto in Instagram:

You may provide an optional state parameter to carry through a server-specific state. For example, you can use this to protect against CSRF issues.

Quando ho elaborato con un diverso code il token CSRF in forma nella pagina in cui l'utente (dis) consente l'accesso al suo account, è lo stesso in tutte le richieste anche se fornisco un valore diverso per code . Va bene?

Hai un'idea di come trasformano code in token CSRF e in che modo viene utilizzato questo token per la protezione CSRF? Per favore, potresti spiegare come funziona?

EDIT1

Ho trovato che un token CSRF per sessione non è probabilmente un problema e generare un token univoco per richiesta porta a un problema applicativo (back-button ecc.), source - link

Ma ancora non so come viene usato il parametro code sopra o trasformato in token CSRF.

csrf

posta Artegon 27.09.2015 - 16:05

fonte

1 risposta

Leggi altre domande sui tag csrf

Il provider SIP memorizza le credenziali, è necessario per alcuni telefoni SIP? Cicli di vita di un virus informatico

score 1 · Answer 1

Do you have an idea how they transform code into CSRF token and how is this token used for CSRF protection? Please could you explain how it works?

Stai mescolando le cose nella tua domanda.

Dalla tua citazione su Instagram:

You may provide an optional state parameter to carry through a server-specific state. For example, you can use this to protect against CSRF issues.

Si noti che è il parametro state utilizzato per la protezione CSRF ed è indipendente da code e da come viene scambiato per un token.

In sostanza, quando l'app invia l'utente su Instagram per eseguire la procedura di autorizzazione, ha bisogno di un modo per garantire che l'utente che torna con un code sia lo stesso e non un utente malintenzionato. È qui che entra in gioco il parametro state , il server di autorizzazione riflette l'eventuale valore presente nel parametro state nell'app chiamante, consentendogli di funzionare come un token CSRF.

Il bit importante è che attraverso l'intera code parte del processo, user-agent funge da intermediario tra l'app e il server di autorizzazione. Il server delle autorizzazioni ha una code per l'app, ma viene assegnato all'utente che lo consegna all'app.

Lo scambio del code per un token non viene gestita tramite il user-agent , il parametro di stato non è più necessario una volta che l'applicazione ha il codice perché comunicante direttamente con la server di autorizzazione (idealmente autenticato con una chiave API e protetto con TLS).

Il codice non viene scambiato per un "token CSRF", il codice viene scambiato per un access_token che consente all'applicazione di eseguire operazioni sulla risorsa protetta (l'account Instagram) sul conto dell'utente.

Il token CSRF inviato nel parametro state è il "lato client" del tuo solito token CSRF (quello che hai inserito in un campo di input nascosto nei tuoi moduli).

Poiché il token CSRF sarà (in base alla progettazione) inviato in GET richieste, è consigliabile renderle univoche e non riutilizzarle. Vedere la divulgazione di Token URL dall'articolo OWASP dalla tua modifica.