Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <465C7C99.4000707@lerdorf.com>
Date: Tue, 29 May 2007 12:18:49 -0700
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Robert Cummings <robert@interjinn.com>
CC: Stut <stuttle@gmail.com>, internals@lists.php.net
References: <465C5D1D.7040206@gmail.com>  <465C6002.5080209@lerdorf.com>	 <1180462052.6874.204.camel@blobule>  <465C6D83.5000000@lerdorf.com> <1180463687.6874.210.camel@blobule>
In-Reply-To: <1180463687.6874.210.camel@blobule>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Session security
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Robert Cummings wrote:
> On Tue, 2007-05-29 at 11:14 -0700, Rasmus Lerdorf wrote:
>> Robert Cummings wrote:
>>> On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
>>>> Stut wrote:
>>>>> Hi all,
>>>>>
>>>>> Just wanted to get your opinion on a discussion currently going on on
>>>>> the general list.
>>>>>
>>>>> Why does the PHP session extension not use something like the user agent
>>>>> to validate that a session ID has not been hijacked? Or is this
>>>>> something that just hasn't been implemented yet?
>>>> The user agent is trivial to spoof.  If you are going to hijack
>>>> someone's session, it is very easy to also hijack their user agent
>>>> string, so I don't see how that solves anything.
>>> I agree mostly, but in the case of idiots that post a URL to a site that
>>> includes a PHPSESSID in the URL it would provide a teency bit more
>>> protection from casual hijacking :)
>>>
>>> I agree more with Xing Xing's responde though, in that it belongs in the
>>> script layer.
>> Well, obviously you need an authentication layer separate from the
>> session layer.  If people are using the session extension as if it was
>> an authentication layer, then they are amazingly misguided.  The
>> solution to that is not the session code, but better documentation.
> 
> Well the two are quite related. Not that the session is responsible for
> authentication, but once authenticated the session data (stored server
> side I hope) usually indicates whether a user has already performed
> authentication for the current temporary session -- otherwise you'd need
> to log back in on every request. As such, a URL posted in the wild
> containing a PHPSESSID is vulnerable to  hijacking for the lifespan of
> the temporary session. Better documentation won't help the completely
> ignorant masses of end users :)

You really want a separate and distinct signed authentication cookie
that has nothing to do with the session.  The stored session should
indicate which logged in user the session belongs to, but it should
never ever be used as the sole authentication cookie.  That's what I
meant by a separate authentication layer.

-Rasmus