Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:16100 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89632 invoked by uid 1010); 26 Apr 2005 17:43:37 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 89527 invoked from network); 26 Apr 2005 17:43:37 -0000 Received: from unknown (HELO pb1.pair.com) (127.0.0.1) by localhost with SMTP; 26 Apr 2005 17:43:37 -0000 X-Host-Fingerprint: 69.17.117.23 mail21.sea5.speakeasy.net Linux 2.5 (sometimes 2.4) (4) Received: from ([69.17.117.23:54160] helo=mail21.sea5.speakeasy.net) by pb1.pair.com (ecelerity 1.2.12rc1 r(5476:5477)) with SMTP id C9/40-59279-FBD7E624 for ; Tue, 26 Apr 2005 13:43:28 -0400 Received: (qmail 1362 invoked from network); 26 Apr 2005 17:43:25 -0000 Received: from out.appliedsec.com (HELO [127.0.0.1]) (hlellelid@[69.17.56.162]) (envelope-sender ) by mail21.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 26 Apr 2005 17:43:25 -0000 Message-ID: <426E7DBB.1050406@velum.net> Date: Tue, 26 Apr 2005 13:43:23 -0400 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Esser CC: Thomas O'Neill , internals@lists.php.net References: <4266894D.1070702@cain.sh> <42668AC0.1010607@caedmon.net> <4269D32C.1080706@cain.sh> <426E6F87.5020908@velum.net> <426E7441.5010101@php.net> <426E7798.4020208@velum.net> <426E79DF.2080900@php.net> In-Reply-To: <426E79DF.2080900@php.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PATCH] Modifications for ext/session/ From: hans@velum.net (Hans Lellelid) Stefan Esser wrote: > Hi, > >> Sorry, perhaps this is just a vocabulary misunderstanding on my part. >> I thought "fixation" was explicitly providing the user with a fake but >> known session id (e.g. '1'), whereas "hijacking" is taking a valid id >> from another user. > > > yeah... Well you call it fake session id. But that is not exactly what > session fixation means. It means you give the user a session ID he will > ride with (and do not steal it from him). ok. > But it makes no difference if you give him a completely fake one or if > you visit the site once yourself and then use the session ID you got for > the fixation. I see your point, but I would still argue that being able to create an arbitrary, non-server-supplied session id is far more powerful -- primarly because it is not susceptible to session garbage collection on the server (i.e. the valid session id I get from the site will be invalid in gc_maxlifetime). Now from last time we had this discussion, I seem to remember you saying that PHP is unable to determine whether a session id is new or not (because of how the session handlers work). If that's the case, then I understand that this is not a problem easy to address in PHP. I do still think it's a problem, however, that session ids in current default (i.e. without using session_regenerate_id()) implementation can be set by the client. I think PHP script authors should be in control of this aspect of their application's security -- i.e. being able to set IDs that cannot easily be brute-forced, etc. -Hans