Re: trans-sid warning?
| From: | Tit \"Black\" Petric | Date: | Mon, 19 Aug 2002 22:49:19 +0000 |
| Subject: | Re: trans-sid warning? | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-87104@lists.php.net to get a copy of this message | ||
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" <rasmus@php.net>
To: "Sascha Schumann" <sascha@apache.org>
Cc: "Yasuo Ohgaki" <yohgaki@ohgaki.net>; <php-dev@lists.php.net>
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
>
>