Posso fidarmi di un ID di sessione per l'unicità?

Sebbene qui vi sia una risposta accettata, è in qualche modo fuorviante.

Can I trust a Session ID for Uniqueness?

Se l'unicità è l'unico vincolo, la risposta breve è sì. Se sei su Facebook o Google, la dovuta diligenza richiederebbe un po 'di tempo per valutare la probabilità che le collisioni si basino sull'algoritmo e sull'architettura dell'applicazione. Per le applicazioni in cui la base utente concorrente sarà inferiore a un milione, il metodo implementato in piattaforme comuni dovrebbe essere sufficiente.

Tuttavia l'univocità riguarda solo la funzionalità del sistema. Da un punto di vista della sicurezza è necessario assicurarsi che l'id della sessione non sia prevedibile, ad esempio

• che non può essere dedotto dai dati disponibili; md5(CLIENT_IP) sarebbe un id di sessione scadente

• che tenta di forzare la forza bruta immagino che l'ID della sessione sia difficile; next_session_id=last_session_id+1 sarebbe una scelta scadente

Se davvero devi implementare la tua generazione di id di sessione, usa un buon generatore di numeri casuali. Dai un'occhiata alle dimensioni degli ID di sessione che il tuo sistema attuale sta generando e miri almeno a tale dimensione nella tua implementazione.

user52472 ha detto:

Storing session tokens in the database could allow an attacker to impersonate other users if they can gain access to these tokens via a SQL injection attack

Dato che l'intero punto delle sessioni lato server è basato sulla memorizzazione lato server, questo può essere meglio indicato come:

L'archiviazione dei token di sessione sul server potrebbe consentire a un utente malintenzionato di dirottare le sessioni se sono in grado di immettere codice che legge lo spazio di archiviazione

.... anche se la natura di SQL è tale che di solito è il frutto appiattito del codice dell'iniezione.

Una soluzione è quella di non archiviare i dati della sessione contro l'id della sessione, ma una sua rappresentazione trasformata (es. sha1 (session_id + salt)) ma questo fornisce solo benefici limitati - se il sale e il meccanismo sono esposti, il meccanismo è inoffensivo. OTOH questo si traduce facilmente in altri substrati di archiviazione.

Se le sessioni sono archiviate in un database relazionale, è possibile proteggerle contro l'enumerazione tramite l'iniezione di codice impedendo l'accesso diretto alla tabella sottostante dall'account utilizzato dall'applicazione, limitando invece le letture e le scritture a un singolo record basato sul chiave (id di sessione) fornita come argomento per una funzione memorizzata con separazione dei privilegi.

Hai ragione, il vecchio sito è il link più debole. Vedo due possibili punti deboli:

1. Il token di sessione non è crittograficamente casuale.
2. L'archiviazione dei token di sessione nel database potrebbe consentire a un utente malintenzionato di impersonare altri utenti se possono ottenere l'accesso a questi token tramite un attacco di SQL injection.

Per il primo, si tratta di ottenere un numero casuale crittograficamente sicuro e assicurarsi che abbia abbastanza bit. Non ho molta familiarità con ASP classico, quindi non potrei dirvi il modo migliore per farlo.

Per il secondo, consiglierei di lasciare che il framework gestisca tutta la gestione della sessione ogni volta che è possibile rimuovere la commissione del vecchio sito. Questo risolverebbe anche il primo problema.