On Monday, August 19, 2002, at 10:24 PM, Xavier Spriet wrote:
> (I might have sent this one twice again...) > ------ > why not simply allow a maximum amount of time a session can exist > (let's say, 25 minutes). > This could be customised or even disabled by the administrator so it > won't be a flea to regular users, and even though it won't be > bulletproof, it will make things considerably more complicated for the > attacker. > Sending a link and hoping it will be clicked in the next 25 minutes is > just trying your luck. Again, this is a good step, but is not at all effective against an attacker motivated to compromise your site. > > Also a good web developer aware of this will most certainly put a > little informing text such as: > You are currently loged in as: you loged in with the following > IPaddr/Uagent: blablah. The problem is, while this means something to the developer, it means nothing to the average end-user, especially since most large ISP users will have ip's that fluctuate form request-to-request. > > Xavier. > > -----Original Message----- > From: Sascha Schumann [mailto:[EMAIL PROTECTED]] > Sent: Mon 19/08/2002 8:50 PM > To: George Schlossnagle > Cc: Rasmus Lerdorf; Yasuo Ohgaki; [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] trans-sid warning? > > > > > To play devil's advocate, pure cookie based authentication is not a > > panacea. If you allow users to put things like javascript on > your site, > > or if you have users who exploit ie bugs like the about: cookie > domain > > bug from last year, cookies can be stolen and session hijacked. > pure > > cookie auth is definitely a good thing, but does not provide > safety in a > > number of 'real world' applications. > > Yes, I pointed that out in an earlier discussion about this > topic. A online-banking site could for example check the > browser for certain types of common vulnerabilities and post > a nice "please upgrade" dialogue. > > This would exclude IE by default though, because there are > quite a load of unfixed, publically known security bugs. > > http://www.jscript.dk/unpatched/ listed them, but the page > seems to be down now. Google still finds > > http://www.jscript.dk/unpatched/MS02-023update.html > > "Yesterday I hosted a list of 14 publickly known unpatched > vulnerabilities, today I host a list of 12 such. It can still > be found at http://jscript.dk/unpatched/ > > - Sascha > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > > > > // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 240.460.5234 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php