L'attaccante riceverà un token CSRF valido se il token di sessione viene rubato?

Question

L'attaccante riceverà un token CSRF valido se il token di sessione viene rubato?

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

0

Il token sincronizzato CSRF ha senso fino a un certo punto. Qualcuno può spiegare il resto in modo infantile a dove posso capirlo.

Quando un utente effettua il login, viene loro assegnato un ID di sessione e un CSRF. L'ID di sessione è memorizzato nei cookie di sessione e il token CSRF è memorizzato solo nella pagina, preferibilmente in un campo nascosto. Quando un utente invia una richiesta che richiede privilegi speciali, il token CSRF viene inviato con esso. Il server verifica che è l'utente e impegna l'azione.

Ok, ecco dove sto avendo il problema Se un utente ottiene il suo id di sessione rubato insieme a qualsiasi altra identificazione, ad esempio da un attacco man-in-the-middle, che non richiede XSS. L'utente malintenzionato non dovrebbe ricevere lo stesso token CSRF assegnato alla sessione a quell'utente?

Ignora le risposte alle intestazioni per la prevenzione, per favore *

web-application attack-prevention

posta White Lotus 18.10.2016 - 23:48

fonte

2 risposte

1

I token CSRF non sono una difesa contro gli altri utenti che accedono al proprio account. I token CSRF sono una difesa solo contro gli attacchi CSRF. Se qualcuno accede a un account (incluso un utente malintenzionato), deve ottenere il token CSRF (insieme a tutti gli altri contenuti normalmente forniti all'utente).

risposta data 18.10.2016 - 23:53

fonte

Leggi altre domande sui tag web-application attack-prevention

Iot devices e wan security [duplicate] DNS Spoof salva IP su Domain Name dopo che l'attacco è terminato, C'è un modo per fermarlo?

score 0 · Accepted Answer

Sebbene le vulnerabilità possano essere incatenate, dobbiamo anche considerare le vulnerabilità da una prospettiva indipendente. Correzioni per una vulnerabilità potrebbe aiutare a correggerne un'altra, ma di solito non è così.

CSRF è l'attacco in cui un utente malintenzionato manipola il trust dell'utente browser. Chiunque abbia una sessione valida dovrebbe avere anche un CSRF token valido perché è così che dovrebbe funzionare l'applicazione. Indipendentemente dal fatto che l'utente abbia rubato session token di qualcun altro, non importa molto all'applicazione qui. Non è possibile per il server identificare se la sessione è stata rubata o no.

Quindi, apparentemente dal punto di vista di un'applicazione, sta usando session id per identificare e mantenere la sessione. Una percentuale disession id rubata non implica il cambio di sessione e quindi l'autore dell'attacco riceverà un CSRF token valido.

Ma se CSRF token non è valido, può capire che la richiesta ha avuto origine da Cross Site e che è stata falsificata.