Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain interjinn.com from 66.11.173.122 cause and error)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Stut <stuttle@gmail.com>, internals@lists.php.net
In-Reply-To: <465C6D83.5000000@lerdorf.com>
References: <465C5D1D.7040206@gmail.com>  <465C6002.5080209@lerdorf.com>
	 <1180462052.6874.204.camel@blobule>  <465C6D83.5000000@lerdorf.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: InterJinn
Date: Tue, 29 May 2007 14:34:47 -0400
Message-ID: <1180463687.6874.210.camel@blobule>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] Session security
From: robert@interjinn.com (Robert Cummings)

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 :)

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'