Rasmus Lerdorf wrote: > 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 >
I don't do that, but some users are using custom session id to share values among users... IMHO, bad practice, though... -- Yasuo Ohgaki > > > 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
