esempio pratico:

quando l'utente ha inserito le sue credenziali sul form controllate se è tutto ok e create questo cookies:

response.cookies("mio")("1") = "NomeUtente"
response.cookies("mio")("2") = session.sessionId

bene questo è un cookie non persistente morirà ogni volta che chiudete il browser.

Poi fatevi una paginetta e scrivete:

if request.cookies("mio") <> "" then
response.write ("devi eseguire il sign out prima di loggarti di nuovo")
else
response.write("Nome" & request.cookies("mio")("1") & "<br>")
response.write("IDsessione" & request.cookies("mio")("2") & "<br>")
response.write("IDsessione reale" & session.sessionID)
End If

Bene ora fate una prova creado il cookie, chiudendo e riamprendo il browser e guardando a che succede. Se tutto è ok avete appena incapsulato l'Id di sessione dentro un cookie che muore tutte le volte che la sessione viene chiusa. Ora nel caso di un session fixation attack, tutto è comunque incapsulato dentro un cookie e quindi le variabili di sessione che in genere si usano (stile session("User") = "nomeuser") non possono essere usate contro di voi.

Alla fine fate un altra prova, e fissate la data di scadenza del cookie riscrivendo le righe della prima pagina così:

response.cookies("mio")("1") = "NomeUtente"
response.cookies("mio")("2") = session.sessionId
response.cookies("mio").expires = DateAdd ("h", 10, Now)

e modificate la seconda così

response.write("Nome" & request.cookies("mio")("1") & "<br>")
response.write("IDsessione" & request.cookies("mio")("2") & "<br>")
response.write("IDsessionereale" & session.sessionID)

chiudete e riaprite il browser, fate partire la prima pagina e poi andate sulla seconda, fatelo più volte controllando il numero della sessione stampata. Questo non dovrebbe mai variare perchè il cookie è persistente. Mentre la sessione in realtà varia.

Bene fateci un pesierino e ditemi se ho scritto una boiata o a se qualcuno interessa. Secondo me gestendo così un login, si rende un pò più difficile la vita di quello che gli inglesi chiamano attacker.

Ciao MrDog, allora l'idea sarebbe questa, mettere in un cookie non persistente (o persistente, è da valutare la cosa) nome e sessionid dell'utente alla login tramite form. Teoricamente anche se uno si impadronisce furtivamente della tua sessione lui non vede tutte le variabili perchè sono incapsulate dentro al cookie.

Poi per ogni pagina protetta controlli la corrispondenza del cookie con il db e lo fai entrare o meno, questo perchè fra la login e l'accesso alle pagine protette può succedere di tutto.

Se l'ID session nel cookie non corrisponde con il session ID attuale vuole dire che la sessione utente è scaduta per qualche motivo e l'utente si deve riloggare.

A dir la verità si può fare anche con un cookie persistente, anzi forse è meglio, dici che il cookie muore dopo 2 ore dalla nacita per esempio, se nel mentre la sessioneid scade dici all'utente di riloggarsi e così se muore il cookie.

Con un cookie persistente e la session incapsulata limiti un possibile attacco a non più del tempo per il quale il cookie è valido e inoltre se uno ruba un cookie quello non sarà mai valido perchè la sessionID è unica. Bhe a dir la verità uno dovrebbe inbrogliare facendo cadere lo user in una session già aperta, poi andarli pure ad intercettare il cookie.

Bisogna pensarci e se mi dai una mano con qualche parere è meglio, e magari se c'è qualche esperto di sicurezza che vuole rispondere è una bella cosa, anche se mi smonta le teorie è uguale, ma è bello discutere secondo me!

---

Modificato da Orsobruno il 04 aprile 2005 22.17 -

Ciao Marco, allora io preferisco controllare se l'utente ha disabilitato i cookies, tanto se li ha disabilitati che tu utilizzi sessions o cookies non persistenti sei sempre fregato. L'utilizzo di un cookie non peristente dovrebbe garantire queste cose:
1) Migliore isolamento con l'esterno rispetto le sessioni (per dire se uno crea una sessione fittizia e vi fa finire nella sua trappola lui sul suo browser non ha cmq i cookies e quindi non dovrebbe accedere sotto falsa identità).
2) Non gravano sul server come invece fanno le sessioni
3) Garantiscono cmq una certa privacy perchè non vengono salvati sull'hard disk dell'utente
4) Se un client decide di cancellare tutti i cookie, almeno con certezza su IE, il cookie non persistente continuerà ad esistere.
5) Se dentro ci incapsuli la sessionId puoi controllare pure che la sessione utente sia cambiata, ad esempio può succedere per un lungo tempo di inattività del client(20 min), la chiusura del browser o per una caduta del server.
Secondo me questo è un metodo valido, ma a me sembra che o io e te siamo gli unici pazzi che pensano a queste soluzioni e si danno risposta, bho o dico cose scontate o forse dico delle assurde porcherie. O forse c'è in giro una confusione assurda su cookis e sessions!

Eh, Eh e lo so sono un pò retrogrado, ma ci passo anche io stai tranquillo: ma già mi barcameno far asp e php, arriverà anche l'ora di asp.net e non credo far molto. cmq ho letto un meccaniscmo di login di asp.net e mi sembra che anche li può settare se adoperare cookie persistenti o non. Poi ad un corso mi vengono a dire che le sessioni non si basano su un cookie, e li mi sono girate le palle! Eh, Eh!