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 v
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 on
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).
Generally speaking I agree
Chris Shiflett wrote:
It would raise the bar, but that's about it.
But isn't that what increasing application security is all about?
Wouldn't that be an example(albeit an arguably small one) of defense in
depth?
An attacker visits your site (to initiate the session), determines the
assigned se
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?
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 vali
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 f
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
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 exa
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 i
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 is is passed
in.
bee
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 p
Nope.
- Sascha
On Tue, 26 Apr 2005, Hans Lellelid wrote:
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 kno
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 de
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 fun
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
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 possibl
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 di
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 i
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() to
20 matches
Mail list logo
