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.
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
