Devo lasciare che il client invii sia la sessione che l'ID utente?

2

Sto lavorando a un progetto in cui gli utenti hanno account e accesso utilizzando il loro nome utente e password se sono corretti il codice restituisce un ID di sessione. La prossima volta che aprono l'app o visitano il sito, ottiene la sessione archiviata e la invia al database e restituisce i dati dell'utente.

I miei problemi sono che cosa succede se qualcuno trova un modo per entrare in un id di sessione fasulla e poi visita il mio sito e se continuano a provare sono obbligati a ottenere una sessione valida.

Nei dati utente e nei cookie della pagina web dell'app oltre alla memorizzazione del token di sessione dovrei anche memorizzare qualcosa come il loro ID utente? Poi, quando visitano il sito, ottengo sia la sessione che l'ID utente per verificare se corrispondono, rendendo più difficile per qualcuno digitare solo sessioni casuali poiché devono trovare una sessione e correggere l'id utente (che è lungo 120 caratteri). / p>     

posta Dan 14.04.2018 - 22:13
fonte

1 risposta

10

Hai ragione che devi assicurarti che l'ID della tua sessione non possa essere forzato brutalmente. Il trucco è rendere l'ID della sessione lungo e casuale (e quando dico random, intendo in modo sicuro casuale ). Se l'ID di sessione viene associato a un ID utente, sarebbe più difficile applicare la forza bruta, poiché l'utente malintenzionato dovrebbe indovinare gli ID per un utente alla volta. Ciò significa che l'ID di sessione potrebbe essere un po 'più breve. Ma dal momento che non ti costa nulla avere un ID sessione lungo, non c'è bisogno di provare ad accorciarlo.

Se usi gli ID di sessione a 64 bit e hai un miliardo di utenti, un utente malintenzionato dovrebbe fare in media 2 64 / 10 9 * 1/2 ≈ 10 < sup> 10 indovina prima di averne una giusta. Senza causare problemi di prestazioni, potresti raddoppiarlo e utilizzare gli ID di sessione a 128 bit, e avrai un margine ridicolo.

Quindi, non c'è nulla di male nell'inviare l'ID utente insieme all'ID di sessione. Ma se usi ID di sessione abbastanza lunghi, non c'è davvero bisogno. Se opti per la soluzione ID utente, ricorda questo:

  • Ovviamente, è necessario verificare effettivamente il lato del server ID utente e non fidarsi ciecamente del client.
  • Supponiamo che l'hacker conosca tutti gli ID utente. Ciò significa che l'ID di sessione deve ancora essere lungo e casuale.
risposta data 14.04.2018 - 23:10
fonte

Leggi altre domande sui tag