-
CookiesScritto daaltgutente che non utieneil 2012-05-28 14:13:20.0 alle 2012-05-28 14:13:20.0Trollate totali: 11540Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.-
Re: CookiesScritto da: altg
> Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?
>
> Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
Hai visto giusto. In qualche modo dovrai pur identificarti al fòro.
Young professional woman and busy mom.-
Re: CookiesScritto daaltgutente che non utieneil 2012-05-28 14:26:17.0 alle 2012-05-28 14:26:17.0Trollate totali: 11540> > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

> >
> > Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
>
> Hai visto giusto. In qualche modo dovrai pur identificarti al fòro.
Ok, era tanto per sapere se non ci fosse qualche escatmo... espca... escamteg... quello li`, che non conoscevo e che passava da qualche altro canale.-
Re: CookiesScritto da: altg
> > > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?
> > >
> > > Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
> >
> > Hai visto giusto. In qualche modo dovrai pur identificarti al fòro.
>
> Ok, era tanto per sapere se non ci fosse qualche escatmo... espca... escamteg... quello li`, che non conoscevo e che passava da qualche altro canale.
Il modo gratuito più sicuro per autenticare l'utente è usare i certificati ssl.
Young professional woman and busy mom.-
Re: CookiesScritto daaltgutente che non utieneil 2012-05-28 18:29:02.0 alle 2012-05-28 18:29:02.0Trollate totali: 11540> > > > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

> > > >
> > > > Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
> > >
> > > Hai visto giusto. In qualche modo dovrai pur identificarti al fòro.
> >
> > Ok, era tanto per sapere se non ci fosse qualche escatmo... espca... escamteg... quello li`, che non conoscevo e che passava da qualche altro canale.
>
> Il modo gratuito più sicuro per autenticare l'utente è usare i certificati ssl.
Cioe` usare l'autenticazione del server col popup che ti chiede username e password?
Se e` quella, e`... brutta a vedersi. In tal caso preferisco il biscotto.
-
-
-
-
Re: CookiesScritto daNon Autenticatoil 2012-05-28 14:44:39.0 alle 2012-05-28 14:44:39.0> Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

>
> Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
Cerca di capire bene questa cosa, se mai un giorno mi servisse saperla me la farò spiegare da te.
-
Re: CookiesScritto daaltgutente che non utieneil 2012-05-28 18:37:21.0 alle 2012-05-28 18:37:21.0Trollate totali: 11540> > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

> >
> > Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
>
> Cerca di capire bene questa cosa, se mai un giorno mi servisse saperla me la farò spiegare da te.
Mi pare di aver capito che non c'e` un modo di evitare il cookie o un passaggio di un session ID tra i parametri di un POST o un GET (il GET poi sarebbe disastroso). Il discorso e` che se uno ti frega il cookie, accede alla tua sessione finche` la sessione non termina (facendo logout o perche` scade, ma di solito non scadono prima di un anno o piu`, per comodita` dell'utente). Il modo per evitare il cookie potrebbe essere passare da qualche altra parte, ma forse non ce ne sono di altrettanto flessibili: la finestrella del login HTTP e`... brutta.
Pero` siccome non ci capisco una sega, hai visto mai mi fossi perso qualcosa e il modo esisteva? Pero` dato che ho visto ::1 usare un cookie per autenticare la sessione QUI, ho dedotto che se non trova un altro modo lui, l'altro modo non esiste o e` talmente inadeguato che conviene passare dal biscotto.-
Re: CookiesScritto daNon Autenticatoil 2012-05-29 00:27:48.0 alle 2012-05-29 00:27:48.0> > > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

> > >
> > > Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
> >
> > Cerca di capire bene questa cosa, se mai un giorno mi servisse saperla me la farò spiegare da te.
>
> Mi pare di aver capito che non c'e` un modo di evitare il cookie o un passaggio di un session ID tra i parametri di un POST o un GET (il GET poi sarebbe disastroso). Il discorso e` che se uno ti frega il cookie, accede alla tua sessione finche` la sessione non termina (facendo logout o perche` scade, ma di solito non scadono prima di un anno o piu`, per comodita` dell'utente). Il modo per evitare il cookie potrebbe essere passare da qualche altra parte, ma forse non ce ne sono di altrettanto flessibili: la finestrella del login HTTP e`... brutta.
>
> Pero` siccome non ci capisco una sega, hai visto mai mi fossi perso qualcosa e il modo esisteva? Pero` dato che ho visto ::1 usare un cookie per autenticare la sessione QUI, ho dedotto che se non trova un altro modo lui, l'altro modo non esiste o e` talmente inadeguato che conviene passare dal biscotto.
Io ricordo una discussione di anni fa sul fatto che PHP passasse automagicamente un identificativo di sessione senza che si veda. In che modo, non l'ho mai capito. Suppongo però che il dato non passi inosservato a uno sniffer che potrebbe perciò impadronirsi della tua sessione e agire come se fossi tu.
In sostanza non ho mai trovato un modo per risolvere il problema.-
Re: CookiesScritto da:
> > > > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?
> > > >
> > > > Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
> > >
> > > Cerca di capire bene questa cosa, se mai un giorno mi servisse saperla me la farò spiegare da te.
> >
> > Mi pare di aver capito che non c'e` un modo di evitare il cookie o un passaggio di un session ID tra i parametri di un POST o un GET (il GET poi sarebbe disastroso). Il discorso e` che se uno ti frega il cookie, accede alla tua sessione finche` la sessione non termina (facendo logout o perche` scade, ma di solito non scadono prima di un anno o piu`, per comodita` dell'utente). Il modo per evitare il cookie potrebbe essere passare da qualche altra parte, ma forse non ce ne sono di altrettanto flessibili: la finestrella del login HTTP e`... brutta.
> >
> > Pero` siccome non ci capisco una sega, hai visto mai mi fossi perso qualcosa e il modo esisteva? Pero` dato che ho visto ::1 usare un cookie per autenticare la sessione QUI, ho dedotto che se non trova un altro modo lui, l'altro modo non esiste o e` talmente inadeguato che conviene passare dal biscotto.
>
> Io ricordo una discussione di anni fa sul fatto che PHP passasse automagicamente un identificativo di sessione senza che si veda. In che modo, non l'ho mai capito. Suppongo però che il dato non passi inosservato a uno sniffer che potrebbe perciò impadronirsi della tua sessione e agire come se fossi tu.
>
> In sostanza non ho mai trovato un modo per risolvere il problema.
L'ho scritto sopra l'unico modo efficace: per ogni client generi un certificato di autenticazione ssl e l'autenticazione avviene all'atto dell'handshake ssl.
Ovviamente l'utente deve installare quel certificato nel suo browser (non è cosa per utonti) e non puoi fare logout senza rimuovere il certificato (e atteso che sia scaduto il keepalive ssl - di solito qualche minuto).
Il pro è che non è un dato accessibile da javascript o falsificabile nelle querystring o da qualunque parte della request.
E` solo un po' più complicato da mettere in piedi perché bisogna sapere cosa si fa.Young professional woman and busy mom.-
Re: CookiesScritto daNon Autenticatoil 2012-05-29 14:26:53.0 alle 2012-05-29 14:26:53.0> > > > > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

> > > > >
> > > > > Lo chiedo perche` stavo cercando di capire se ci fosse un modo per mettersi al sicuro anche nel caso che qualcuno riesca a farsi recapitare document.cookie.
> > > >
> > > > Cerca di capire bene questa cosa, se mai un giorno mi servisse saperla me la farò spiegare da te.
> > >
> > > Mi pare di aver capito che non c'e` un modo di evitare il cookie o un passaggio di un session ID tra i parametri di un POST o un GET (il GET poi sarebbe disastroso). Il discorso e` che se uno ti frega il cookie, accede alla tua sessione finche` la sessione non termina (facendo logout o perche` scade, ma di solito non scadono prima di un anno o piu`, per comodita` dell'utente). Il modo per evitare il cookie potrebbe essere passare da qualche altra parte, ma forse non ce ne sono di altrettanto flessibili: la finestrella del login HTTP e`... brutta.
> > >
> > > Pero` siccome non ci capisco una sega, hai visto mai mi fossi perso qualcosa e il modo esisteva? Pero` dato che ho visto ::1 usare un cookie per autenticare la sessione QUI, ho dedotto che se non trova un altro modo lui, l'altro modo non esiste o e` talmente inadeguato che conviene passare dal biscotto.
> >
> > Io ricordo una discussione di anni fa sul fatto che PHP passasse automagicamente un identificativo di sessione senza che si veda. In che modo, non l'ho mai capito. Suppongo però che il dato non passi inosservato a uno sniffer che potrebbe perciò impadronirsi della tua sessione e agire come se fossi tu.
> >
> > In sostanza non ho mai trovato un modo per risolvere il problema.
>
> L'ho scritto sopra l'unico modo efficace: per ogni client generi un certificato di autenticazione ssl e l'autenticazione avviene all'atto dell'handshake ssl.
> Ovviamente l'utente deve installare quel certificato nel suo browser (non è cosa per utonti) e non puoi fare logout senza rimuovere il certificato (e atteso che sia scaduto il keepalive ssl - di solito qualche minuto).
> Il pro è che non è un dato accessibile da javascript o falsificabile nelle querystring o da qualunque parte della request.
> E` solo un po' più complicato da mettere in piedi perché bisogna sapere cosa si fa.
Ma in genere gli hosting aggratuiti non forniscono supporto a SSL. Per cui ho sempre cercato una soluzione implementabile in PHP, ma è come cercare il passaggio a nordovest.
-
-
-
-
-
Re: CookiesScritto daNon Autenticatoil 2012-05-28 15:50:36.0 alle 2012-05-28 15:50:36.0Scritto da: altg
> Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?
Chiedilo a Mastro Biscotto

-
Re: CookiesScritto daNon Autenticatoil 2012-05-28 16:42:14.0 alle 2012-05-28 16:42:14.0> > Ma il forumdeitroll usa un cookie per autenticare? Ne trovo uno chiamato JSESSIONID. Mi era parso di capire che il FdT fosse reso immune a un XSS, ma se e` cosi`, come si mette al sicuro? Se qualcuno mi frega il cookie con il JSESSIONID, non avrebbe accesso alla mia sessione?

>
> Chiedilo a Mastro Biscotto


Già, è un po' che non si fa vivo.
-
-