Jani Taskinen wrote: > > I was wondering (I'm propably wrong, it's almost 6am here :) > that wouldn't the real fix for this without having to add > yet-another-ini-option have been to fix this so that > logic with session.use_cookies and session_use_trans_sid > worked like it was (?) meant to work.
I agree. That should be the same. But what about use_cookie=1 and use_trans_sid=1 situation? When should we allow to fallback from cookie to URL propagation? Shouldn't the GPC rule apply here too? I know the problem with the very first hit, when we know nothing of cookies enabled or not.. But the session offered in the url is checked and eventually created, before the firts redirect/cookie_check. SO at this point, before the initial redirect, we know if this is a 'living' or a 'newborn' session. I wonder if, even at the application level, it would make sense to trigger this with the canges in the propagation mode, and block any downgrade in propagation mode. But I slept only a few hours too. It is unusual that the same client would switch cookies on/off amid the way, and if this happens we are probably facing a client qui pro quo. Once the client has proven to be cookie-enabled, why should we accept a lower level, if we don't expressly want it (use cookies if they are enabled). I know counting on the possibility to force a downgrade in the propagation mode is a very common practice of writing code, but we should be able to do the same with a little bit more of control. So these directive should be overridable on a per script basis. Giancarlo > > ie. session.use_cookies=1 and session_use_trans_sid=0 > would not use any other session id but the one provided > by the cookie? btw. Cookies can be forged too.. > > --Jani > > > On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote: > > >Hi. > >Last here, same period, I found that nasty thing in > >?_PHPLIB[libdir]=http://.... > >It was the nefarious start of the register_globals=off saga. > > > >Now Sascha has agreed to add a session.use_only_cookie directive, > >because session.use_cookie wasn't doing it really all the times. In > >fact, contrary to what advertised, session.use_cookie doesn't uses > >cookies if a SID is found in the URL, and can so be forced to use a > >user_provided variable when it should not. > > > >The winning argument, for the new session.use_only_cookies, has been > >that, with the actual settings, there cannot exist a situation in which > >PHP would discard the ID in the URL, and go cookie_or_nothing, as the > >banks do. > >It is forceable. Even if the client has cookies enabled. > > > >You know, really secure sites use *only cookies* propagation, or you > >don't do your home banking. Because cookies are the closest thing that > >can assure that we are speaking to the same client, that noone can > >takeover a session. > > > >The basis for this behavior of session.use_cookie is that we may not > >know when coookies are enabled, not on the very first hit, when I > >suppose a redirect to self is made and the cookie is then checked for > >presence. > > > >The aim to use cookies, if available, is because cookie is an acronym of > >'not transferrable among clients that support cookies', that is it goes > >as close as possible to identify a single client. > >My interpretation of session.use_cookie is: if cookies are enabled, try > >to use them as a propagation because they cannot be transferred among > >clients > >(see the acronym above). > >If this is the aim, and on coming back from the redirect we found a > >cookie, still the presence of a user-provided SID in the url should make > >us suspicious. > >If we want to prevent session takeovers, here we are in presence of a > >transfer. We couldn't know that cookies were enabled the very first hit, > >but now we know it, and there is a SID in the URL... someone is forcing > >a transfer. Discard the sid and issue a new cookie. > > > >Once we know cookies are enabled we should stick to them, not because > >they are a better way of storage, but because tey guarantee uniqness of > >the client. > >So why should we allow a transfer from outside? > > > >All this is apart from other concerns, as the possibility to create > >session_id at will, with pleasing and easy-to-remember values, to be > >offered around for those 'social engineering' attacks, with no hope for > >the poor cookie-enabled victim to avoid it. > > > >Isn't his similar to the register_globals=on problem, where untrusted > >user provided values can make their way inside the script? Isn't this > >variable even more important, to let it in? > > > >Giancarlo Pinerolo > > > > > > -- -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
