Accesso Google+ - Flusso One Time Code vs Pure Server Side flow

4

Sto leggendo la documentazione su Google+ Accedi, più specificamente, il suo flusso sul lato server. Dice ( link ) che il flusso di codice una tantum presenta vantaggi di sicurezza rispetto al puro lato server flusso. Dice:

"This one-time code flow has security advantages over both a pure server-side flow and over sending access tokens to your server."

Riesco a vedere i vantaggi del flusso di codice monouso rispetto all'invio del token di accesso al server ma non riesco a vedere i vantaggi di un flusso di codice temporale rispetto al flusso lato server puro. Mi stavo chiedendo se qualcuno potrebbe indicarne qualcuno.

    
posta markovuksanovic 13.09.2014 - 12:01
fonte

2 risposte

4

Sembra che l'unico vantaggio in termini di sicurezza è che se si utilizza il flusso di codice una tantum, il componente browser e il componente server del client ricevono ciascuno il proprio token. Nel puro flusso lato server, solo il server ottiene il token e il flusso dell'applicazione Web solo il client riceve il token. L'invio di token dal client al server e viceversa espone l'utente finale a un determinato rischio. Usando il flusso di codice una tantum non ci sono token di invio dal client < - > server e il rischio che i token vengano compromessi è inferiore.

    
risposta data 27.09.2014 - 15:59
fonte
1

"Questo flusso di codice monouso ha vantaggi in termini di sicurezza ..." L'affermazione è assolutamente valida considerando uno degli attacchi più pericolosi che una applicazione web possa subire. Si tratta del Cross Site Request Forgery (CSRF in breve).

Prima di spiegare il vantaggio del codice monouso, lasciami chiarire il concetto di CSRF. CSRF è il numero 8 nell'elenco OWASP delle vulnerabilità più pericolose del 2013. Se un'applicazione Web è vulnerabile a CSRF, è possibile eseguire qualsiasi script per l'hacker a livello dell'utente, a condizione che l'utente debba accedere. accade che l'attaccante crei url o richieste POST contenenti codici dannosi, che possano essere anche i codici JS per prelevare i cookie di sessione dell'utente e inviarli all'hacker. Ora questi URL vengono inviati all'utente di destinazione tramite e-mail e chat. Le richieste POST sono implementate nel proprio sito dall'hacker e il collegamento viene dato alla vittima nello stesso modo. Poiché l'utente ha effettuato l'accesso, dopo aver fatto clic sul collegamento, gli script nascosti verranno eseguiti dall'utente finale e quest'ultimo viene violato.

L'unico metodo di prevenzione contro CSRF è implementando i token in ogni pagina. Una volta che l'utente accede al proprio account, il server assegna i token CSRF a ciascuna pagina dell'applicazione Web. Ora che ogni volta che si fa clic sui collegamenti, il token CSRF viene inviato al server e il server fornisce l'autorizzazione solo se accetta tale token. Quello che devi pensare che un link cliccato da e-mail o chat avrà un token CSRF diverso e quindi impedisce questo attacco.

    
risposta data 22.09.2014 - 16:52
fonte

Leggi altre domande sui tag