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
