(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.
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.
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