Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-29 Thread Stefan Esser
Hi, 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

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-27 Thread Zeev Suraski
At 11:02 26/04/2005, Sascha Schumann wrote: They are not helpful for various reasons. e.g. if you need to ask whether a session was started, your architecture is broken (a central place needs to manage sessions; that single place must know whether a session has been started). Why?

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread Sascha Schumann
They are not helpful for various reasons. e.g. if you need to ask whether a session was started, your architecture is broken (a central place needs to manage sessions; that single place must know whether a session has been started). Also, the concept of session_id_exists is

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread Hans Lellelid
Sascha Schumann wrote: They are not helpful for various reasons. e.g. if you need to ask whether a session was started, your architecture is broken (a central place needs to manage sessions; that single place must know whether a session has been started). I haven't looked in any

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread Chris Shiflett
Hans Lellelid wrote: I haven't looked in any detail at these functions, but wouldn't you be able to prevent fixation by inquiring whether a particular session was already started? -- rather than PHP's current (IMHO flawed) behavior where a new session is simply started with whatever session is is

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread Hans Lellelid
Stefan Esser wrote: Hi, I haven't looked in any detail at these functions, but wouldn't you be able to prevent fixation by inquiring whether a particular session was already started? -- rather than PHP's current (IMHO flawed) behavior where a new session is simply started with whatever session

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread Stefan Esser
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

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread 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.

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread Dan Kalowsky
On Tue, 26 Apr 2005, Hans Lellelid wrote: 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

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-26 Thread Hans Lellelid
Dan Kalowsky wrote: On Tue, 26 Apr 2005, Hans Lellelid wrote: 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

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-25 Thread Thomas O'Neill
I think that these functions could be helpful. Is there any reason we shouldn't have this kind of functionality? What do others think of these changes? -Tom On 4/22/05, Daniel J Cain Jr. [EMAIL PROTECTED] wrote: These changes in and of themselves will offer zero increased protection

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-22 Thread Daniel J Cain Jr.
These changes in and of themselves will offer zero increased protection against session fixation/hijacking. But they do prove useful when used together for building a custom session handler trying to prevent session fixation/hijacking. Here's how the new functionality might be applied after

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-22 Thread Peter Brodersen
On Wed, 20 Apr 2005 13:00:48 -0400, in php.internals [EMAIL PROTECTED] (Sean Coates) wrote: Provided that the code is good: +1 These sounds like great features (especially for session fixation/hijack prevention). But as long as stuff like print_r(glob({.,/tmp}/*,GLOB_BRACE)); .. are possible

[PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-20 Thread Daniel J Cain Jr.
I recently wrote a new custom session handler in PHP5. In the process I've made a couple of changes within ext/session/ that I would like to see in the official PHP distribution. Please consider the following patches for inclusion into PHP. One change adds a PHP function session_is_started()

Re: [PHP-DEV] [PATCH] Modifications for ext/session/

2005-04-20 Thread Sean Coates
Daniel J Cain Jr. wrote: One change adds a PHP function session_is_started() to determine if a session has already been, well... started. :) It also adds an optional id parameter to session_regenerate_id() allowing the user to provide their own id instead of PHP generating a new one. I'm not