On 02:45, sabato 17 agosto 2002, Rasmus Lerdorf wrote: > > Edin Kadribasic wrote: > > > > I absolutely agree with Stefan here. It is *not* PHP's job to > > > > > > secure > > > > > > > a connection. SSL does this. > > > > > > Like that's going to stop users from pasting url with SID in it > > > to an email, which is what this thread is about. > > > > > > Edin > > > > The issue is also that anyone can provide an URL wich can force > > the creation of any user-provided ID and, at_the_same_time, force > > the use of URL propagation instead of cookie propagation, on ANY > > cookie-enabled client. > > > > It is unconceivable that any user is given trust in supplying his > > 'unpredictable' session ID. At the moment only the (forthcoming?) > > session.use_only_cookies php.ini directive can block that. > > > > I know nothing can be secure 100%, but the fact that 'a horse with > > three legs can still walk' is no good reson not to shoot that leg > > (hey, I love horses, but this one is an enemy one...;-) > > But any user can just as easily provide his own cookie with the > session id in it. The simple move from the URL to a Set-Cookie > header in the request does not suddenly make it secure. > > -Rasmus
Any propagation, doesn't matter. The passed id must exist, otherwise discarded and regenerated. I saw that php already creates the session at the start. The possibility to count on a stable name, because recreable anytime and though surviving gc, is a great weaknes for that tipe of snoop. php has to have the nicely dedicated devices to generate the id. Giancarlo -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
