crixo ha scritto:

Davvero molto interessante...

Grazie

se ho capito bene, tutto funziona se si riesce ad ottenere l'id di sessione dell'utente collegato...

No, non è esatto: l'attacco funziona forzando il SessionId tramite JavaScript. Mi spiego meglio: l'ID della sessione risiede sul client, salvato nel cookie ASP.NET_SessionId ed è possibile variarne il valore come dimostrato nella demo (rif. funzione js "runXSS")

ma come ritieni possibile che chi effettua l'attacco conosco l'id di sessione generato per l'utente che si vuole attaccare?

Come dicevo prima il principio è l'esatto inverso. Se provi ad eseguire la demo vedrai che l'id delle sessioni assume un fantomatico valore "SessionIdRubataUsandoXSS"

HTH

m.casati ha scritto:

l'ID della sessione risiede sul client, salvato nel cookie ASP.NET_SessionId

ma essendo un coockie di tipo HttpOnly non e' leggibile via js... ma solo tra gli header della richiesta

è possibile variarne il valore come dimostrato nella demo (rif. funzione js "runXSS")

questo punto mi e' chiaro... ma per settarlo occorre conoscere un id di sessione valido... ovvero il primo punto mi sfugge ancora

Ps sto cercando di capire come potrebbe funzionare il furto del sessionid, non per metterlo in pratica, bensi per prevenirlo

crixo ha scritto:

non e' un problema di conoscere l'id di sessione, ma di modificarlo
nella prima parte si cambia il valore del cookie per l'utente
nella seconda si setta il cookie di chi vuole hackerare il sito allo stesso valore precedentemente modificato cosi da caricare la precedente sessione
corretto??

Esatto!