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
