I moduli web di Asp.net non generano un nuovo ID di sessione se un utente si disconnette e si riavvia. È questo un grave rischio per la sicurezza? Stiamo utilizzando SSL.
I moduli web di Asp.net non generano un nuovo ID di sessione se un utente si disconnette e si riavvia. È questo un grave rischio per la sicurezza? Stiamo utilizzando SSL.
In ASP.NET è normale che riutilizzi un ID di sessione . Per quanto riguarda i dati memorizzati nella sessione, se si desidera assicurarsi che i dati non siano accessibili una volta che l'utente si è disconnesso, è possibile chiamare Session.Abandon () nella funzionalità di disconnessione. Ma anche se non si chiama Abandon, la sessione non è più vulnerabile di quanto non lo sia quando l'utente ha effettuato l'accesso. L'abbandono semplicemente lo costringe a ripulirlo prima che impieghi una sessione inutilizzata (penso che la il valore predefinito è 20 minuti). È sempre una buona idea chiamare Abandon per impedire il dirottamento di sessione dopo che qualcuno si disconnette e si allontana da un computer condiviso.
Dovremmo chiarire una cosa prima di spostarne una:
Questo non significa che sia sicuro, ma non significa che non sia sicuro.
Ora lavoriamo attraverso il computer di stato delle sessioni utente durante l'intera transazione e vediamo cosa succede con i dati nella sessione:
Il computer passa al servizio web, ottiene la sessione id=X e i dati della sessione vengono archiviati nel DB come id = X, session_data = {"User": null, "IP_address":..., "Mac":..., "Other_device_specific_info":...}
Gli accessi utente e i dati di sessione nel database vengono aggiornati come UPDATE sessions SET session_data->user = Y WHERE id = X; . La sessione è stata aggiornata per riflettere le modifiche e le modifiche ai permessi, ma non è necessario aggiornare l'ID della sessione perché è la stessa macchina, nella stessa visita .
L'utente fa un po 'di cose e il parametro session_data viene aggiornato di nuovo, impostando altri valori in esso da tracciare.
Ora l'utente si disconnette e la sessione distrugge i dati, ma mantiene l'id e fa una nuova sessione fresca con lo stesso id perché è la stessa macchina nella stessa visita e ora assomiglia a id = X, session_data = {"User": null, "IP_address":...} che è identica alla sessione originale, non utente.
Ora un altro utente accede e facciamo di nuovo le stesse cose.
Poiché l'ID di sessione è stato effimero / scaduto, alla fine verrà distrutto e quindi quando la macchina tornerà a visitare avrà un nuovo ID di sessione.
Come puoi vedere, finché il back-end è stato progettato correttamente, utilizzare lo stesso ID di sessione non è affatto un problema. L'IT (sia esso che IT) sarebbe un problema se gli stessi dati della sessione sono stati riutilizzati.
Tutto presuppone che i dati di sessione e l'ID siano tracciati correttamente e il servizio Web non sia vulnerabile a causa dell'ID di sessione associato alla macchina e non all'utente.
Solo perché un ID di sessione è collegato a una macchina e non a un utente, non significa che sia stato impostato in modo errato. Significa solo che probabilmente stanno anche monitorando ciò che gli utenti hanno usato quali macchine, per quanto tempo a scopi metrici.
Probabilmente dovresti utilizzare Google questi termini per assicurarti che la configurazione sia sicura
Sì, ciò potrebbe dar luogo a una vulnerabilità per la risoluzione della sessione .
Supponiamo che il tuo sito sia su example.com e consenti agli utenti di caricare le proprie pagine su usercontent.example.com per proteggersi dallo scripting cross-site.
Potresti pensare che i cookie su example.com siano al sicuro da qualsiasi script in esecuzione su usercontent.example.com perché solo-flag-host è impostato di default sui cookie di sessione. Tuttavia, un utente malintenzionato potrebbe eseguire un attacco nel modo seguente:
L'attaccante visita example.com e ottiene un ID di sessione - ne prende nota.
L'utente scarica alcuni contenuti in usercontent.example.com , inclusi alcuni JavaScript per impostare un cookie a example.com level per impostare l'ID di sessione su di lei.
L'autore dell'attacco incita un utente amministratore a example.com a visitare la pagina dell'attaccante su http://usercontent.example.com/evil_page .
Ora l'attaccante e la vittima hanno lo stesso ID di sessione. All'attaccante è stato dato l'ID di sessione dal server, alla vittima è stato dato l'ID di sessione dalla pagina malvagia dell'attaccante.
L'utente malintenzionato attende che la vittima effettui l'accesso a example.com . Poiché il sito non ruota gli ID di sessione, anche l'autore dell'attacco verrà registrato come amministratore.
Voila - un attacco di fissazione della sessione.
Se questo è possibile o meno con l'applicazione dei moduli Web dipende dal fatto che utilizzi l'autenticazione basata su moduli o l'ID sessione per tenere traccia delle sessioni utente. Vedi questa risposta . Autenticazione moduli genera un nuovo token per ogni accesso, quindi non dovrebbe essere vulnerabile. Tuttavia, se Session viene anche utilizzato e considerato attendibile durante l'accesso, questo può anche essere sfruttato da un utente malintenzionato per controllare un amministratore malintenzionato utilizzando la fissazione della sessione, a seconda della funzionalità del sito.
Leggi altre domande sui tag session-management