Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16148
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42727BBE.1070305@cain.sh>
Date: Fri, 29 Apr 2005 13:23:58 -0500
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: internals@lists.php.net
References: <4266894D.1070702@cain.sh> <42668AC0.1010607@caedmon.net>	<pkhi61di24djruht2uhqhjfppn6bt6dsme@4ax.com> <4269D32C.1080706@cain.sh>	<d0cb926205042518356213b551@mail.gmail.com> <Pine.LNX.4.61.0504260952410.29267@chatserv> <426E6F87.5020908@velum.net> <426E7441.5010101@php.net>
In-Reply-To: <426E7441.5010101@php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Modifications for ext/session/
From: dan@cain.sh ("Daniel J Cain Jr.")



Stefan Esser wrote:
> beeing able to detect if a session was already started has nothing todo 
> with session fixation attacks.

It does have *something* to do with session fixation attacks.  In that
if you are given a session ID that doesn't exist it's most likely an 
expired session ID (make a new one) or a possible fixation attack (make 
a new one).

> Session fixation means that you supply the user with a session id you 
> know about. It doesn't make any difference if this session id was 
> obtained by visiting the target site once, or by simply putting in a 
> random one (that is then accepted by PHP).

That's a very good point!  It's often overlooked that a fixation attack
may use a *valid* session ID, instead of just generating a random one.

I would prefer to make the attacker grab a valid session ID from me 
rather than simply allowing them to generate their own random one.  It 
would simply mean the attacker would need a slightly more complex script 
to automate attacks.  As well as applying a possible time frame the 
attack is valid for.  Which isn't a bad thing IMO.

> (And any argument that one obtained by visiting the site would be bound 
> to the attackers creds is invalid, because the same technique would 
> catch new invalid sessions (because of no assigned creds))
> 
> And the behaviour of PHP is not flawed. For several systems it is vital, 
> that the outside is able to set the session id. There is no reason to 
> change that behaviour, because it doesn't stop any attack.

I agree, PHP is certainly not flawed.  Some of our production servers
depend on being able to set the session ID externally.  I wouldn't 
propose changing PHP's behavior to not accept a remote session ID.  But 
I would propose (if possible) providing the user a tool that they could 
implement it if they so desire(i.e., session_id_exists()).

-- 
D  a  n  i  e  l     J     C  a  i  n     J  r .
                          Zend Certified Engineer
http://zend.com/zce.php?c=ZEND001685&r=210869656