maybe you should implement a "dynamic_sid" flag, which would make SID behave in the following way
page.php?sid=sidvaluekey after you would visit that page, you would get all url's in the page encoded with page.php?sid=newvaluekey so basically, the SID value expires (or should i say "mutates") on each pageload, this can be done with set-cookie or in url, either way, the only problem still exists if people paste page.php?sid=newvaluekey before they acctually visit it. p.s. storing "IP/USERAGENT/whatnot" on the server, matching it with the SID would probablly decrease the number of session hijackings, i just dont know if that behaviour should be the default one. imo, letting the user change it in php.ini would be more appropriate in case somebody see's a problem inside this? matching ip limits the number of session hijackings to atleast the same network you are on (behind a fw/router which does nat), and the users who use the same http proxy as you (in case you use one) so its either expire/generate (rotate,morph,mutate) SID on each pageload, or the more popular sollution... IP match ----- Original Message ----- From: "Rasmus Lerdorf" <[EMAIL PROTECTED]> To: "Sascha Schumann" <[EMAIL PROTECTED]> Cc: "Yasuo Ohgaki" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, August 20, 2002 12:27 AM Subject: Re: [PHP-DEV] trans-sid warning? > Well, while it is true that it is impossible to completely prevent, our > current setup doesn't do anything at all to prevent it which makes the > attack much simpler. There is currently no need for the attacker to visit > the site to be attacked at all and thus he doesn't need any keepalive > stuff to make sure the SID stays active. He can simply make up any SID he > wants and trick the victim into visiting the site. As soon as the > attacker sees that a victim has clicked, he can follow that victim in > since there is no check in PHP that ensures that a SID is a valid active > session. I don't see any reason to allow visitors to specify their own > custom SID. What is the benefit to that? > > -Rasmus > > > > On Mon, 19 Aug 2002, Sascha Schumann wrote: > > > > Well, more worrisome would be if a bad guy tricks you into clicking on a > > > link or simply sends you an image in an email that makes a request to my > > > server with a valid-looking session id. Then if you go to this site (that > > > > I've debunked that scenario already a few times. The net > > result is that this class of attacks is impossible to > > prevent. > > > > The assumption in your scenario and the following is this: > > > > The attacker has access to a script X which calls > > session_start(). > > > > My scenario: > > > > 1.) Attacker A accesses X and stores the SID which PHP assigns > > to him. > > > > 2.) A crafts a link containing SID and sends it to victim V. > > > > 3.) A keeps SID alive by repeatedly accessing X using SID. > > > > 4.) V opens link and authenticates. > > > > 5.) A's script notices (4). A can overtake V's session. > > > > - Sascha > > > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
