GWT: memorizzazione dell'ID sessione nel cookie, e poi?

Question

Attualmente sto creando un sito utilizzando GWT, ospitato su AppEngine. Lo sto facendo con i miei accessi personali che sto facendo (so che Google fornisce qualcosa con GWT, ma ho bisogno del mio sistema di login), e ho cercato di capire le sessioni da un po 'di tempo. Ho trovato alcuni tutorial e uno dei siti che stavo leggendo è http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

C'è una sezione in "Come ricordare gli accessi". So come ottenere l'ID di sessione e memorizzarlo sul client in un cookie tramite una chiamata RPC. Quello che non capisco è che, alla fine, dopo circa un giorno, l'utente torna e io dovrei ottenere l'ID di sessione dal cookie e inviarlo al server. Cosa dovrei fare sul server per valutare in modo sicuro se l'ID di sessione è ancora legale e recuperare tutte le informazioni necessarie sull'utente?

Altre domande: 1. Che cosa cambierebbe l'ID di sessione? 2. Cosa succede se l'utente era su un laptop e l'utente è andato da qualche altra parte. Sarebbe ancora in grado di riconnettersi in modo sicuro senza dover digitare nuovamente login e password?

Grazie!

~ Scott

Answer 1

Per ricordare gli account di accesso è necessario generare in modo sicuro un unico ID di sessione. Normalmente, questo è inserito in un cookie. Consiglierei l'uso di un framework che faccia i cookie di sessione per te. Sbagliare può lasciare il tuo sito aperto ad abusi. Le cose da considerare sono:

• Hai bisogno di preoccuparti di rubare i cookie. L'indirizzo IP dell'utente deve essere codificato nell'ID di sessione o collegato all'ID di sessione. Controlla l'indirizzo IP su ogni accesso alla pagina.
• Accertarsi che gli accessi siano su sessioni crittografate. Altrimenti esponi le credenziali in chiaro sulla rete.
• Per quanto tempo dovrebbero durare le sessioni. Dovrebbero scadere dopo un limite di tempo prefissato. Questo può essere lungo ore o giorni.
• Ricordarsi di me dovrebbe essere diversa funzionalità su un cookie diverso. Deve contenere qualcosa che possa essere usato per identificare l'utente. A seconda dei requisiti di sicurezza potrebbe essere necessario un valore crittografato. Questo cookie può avere un timeout più lungo.

Le risposte alle vostre domande aggiuntive sono.

1. È probabile che nulla sul lato client cambi l'ID di sessione. L'ID di sessione dovrebbe essere rigenerato ogni accesso.
2. A seconda della sicurezza dell'ID di sessione, potrebbe essere necessario effettuare il login. I cookie di sessione sicura codificano spesso l'indirizzo IP per impedire il furto dei cookie. In tal caso, l'utente del laptop dovrà effettuare nuovamente il login.

Answer 2

domanda simile: question on GWT, Cookies and webpage directing.
Una cosa importante da ricordare: non fare affidamento solo sui cookie: trasferire l'ID/token di sessione nel payload della richiesta e confrontarlo con il valore del cookie sul lato server. Ciò impedirà gli attacchi XSRF. Questo è il genere di cose di cui dovresti essere preoccupato.

La politica su come gestire gli ID di sessione dipende da quanto seriamente si prende sicurezza nella propria applicazione e dal tipo di applicazione.Ad esempio, è possibile accedere con lo stesso token su GMail da diversi IP: presumo che lo abbiano consentito perché è comune che l'IP dell'utente cambi durante le sessioni. Hanno tuttavia aggiunto una funzionalità che consente di vedere da quali IP l'utente ha effettuato l'accesso di recente. E non dimenticarti degli utenti con IP dinamici (un numero piuttosto elevato): se tieni traccia dei token e degli IP, in pratica non consentirai a quegli utenti di rimanere loggati tra una sessione e l'altra.

Cosa dovrei fare sul server al fine di valutare in modo sicuro se ID di sessione è ancora legale, e tirare su tutte le informazioni necessarie circa l'utente?

È necessario tenere traccia degli ID sessione/coppie di accesso nel DB.

Cosa farebbe cambiare l'ID di sessione?

O scade o l'utente tenta di accedere con un token che non è associato al loro IP. È possibile aggiungere anche le proprie regole, come il numero di accessi, ecc. Per maggiore sicurezza, è possibile generare un nuovo ID/token di sessione su ogni nuovo accesso/sessione (l'utente si autentica con il vecchio token, il server verifica che sia valido e rimanda all'utente il nuovo token che dovrà usare d'ora in poi).