Everything

php

why does PHP accept [new] session ids from client?

php.internals

Hans Lellelid

21 years ago

Hi,

This may not be the right place for this question, but what I'm looking
to understand is the reasoning behind what seems to be the standard
session behavior in PHP.  And, if it's possible, how to change this
behavior (via INI settings, etc.).

As I understand (and experience) it, if a client [browser] presents a
session id (e.g. in a cookie) to the server, then PHP will attempt to
match that ID to the session on the system.  If found, that session
information will be made available to the scripts.  Fine.  But, if *not
found* then a new session will be created with the specified ID.

Is there any way to disable this behavior?  I can't think of a single
circumstance under which this would be the desired behavior, but my use
of sessions has been more limited to authentication & web applications.
I know about using session_regenerate_id() after authentication, to
prevent fixation, but it seems like this is a workaround for a more
fundamental problem in PHP session behavior.

On a side note, does anyone know if Hardened-PHP exhibits the same behavior?

Thanks,
Hans

Jeremy Johnstone

21 years ago

Not to be rude or anything, but this question is better suited for php-general

-Jeremy

On Tue, 29 Mar 2005 12:47:29 -0500, Hans L <hans@velum.net> wrote:

> Hi,
>
> This may not be the right place for this question, but what I'm looking
> to understand is the reasoning behind what seems to be the standard
> session behavior in PHP.  And, if it's possible, how to change this
> behavior (via INI settings, etc.).
>
> As I understand (and experience) it, if a client [browser] presents a
> session id (e.g. in a cookie) to the server, then PHP will attempt to
> match that ID to the session on the system.  If found, that session
> information will be made available to the scripts.  Fine.  But, if *not
> found* then a new session will be created with the specified ID.
>
> Is there any way to disable this behavior?  I can't think of a single
> circumstance under which this would be the desired behavior, but my use
> of sessions has been more limited to authentication & web applications.
>   I know about using session_regenerate_id() after authentication, to
> prevent fixation, but it seems like this is a workaround for a more
> fundamental problem in PHP session behavior.
>
> On a side note, does anyone know if Hardened-PHP exhibits the same behavior?
>
> Thanks,
> Hans
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
---------------------------
Jeremy Johnstone
http://www.jeremyjohnstone.com
jsjohnst@php.net

Hans Lellelid

21 years ago

Ok, I'll post it there.  I thought that it was more a question of "why
is it this way?" than "how do I do XXXX?".

Thanks,
Hans

Jeremy Johnstone wrote:

M. Sokolewicz

21 years ago

"why is it this way" should also be posted to the general newsgroup, it
barely has anything to do with internals

- tul

Hans L wrote:

Chris Shiflett

21 years ago

M. Sokolewicz wrote:

> "why is it this way" should also be posted to the general newsgroup, it
> barely has anything to do with internals

The behavior of the session extension has everything to do with
internals. I'm not sure why everyone is sending him to php-general. No
one there is going to be able to change this behavior. They can only
suggest userland code to try to work around it.

The problem is that PHP uses any user-supplied session identifier when
creating a new session. This increases the risk of session fixation.

If this behavior were changed, it would not completely protect
developers from session fixation, but it would be a step in the right
direction. I think the original poster was making this suggestion.

Chris

Hans Lellelid

21 years ago

Hi Chris,

Chris Shiflett wrote:

> M. Sokolewicz wrote:
>
>> "why is it this way" should also be posted to the general newsgroup, it
>> barely has anything to do with internals
>
>
> The behavior of the session extension has everything to do with
> internals. I'm not sure why everyone is sending him to php-general. No
> one there is going to be able to change this behavior. They can only
> suggest userland code to try to work around it.
>
> The problem is that PHP uses any user-supplied session identifier when
> creating a new session. This increases the risk of session fixation.
>
> If this behavior were changed, it would not completely protect
> developers from session fixation, but it would be a step in the right
> direction. I think the original poster was making this suggestion.
>

Thanks, Chris.  Yes, that's what I was suggesting.  I think I may be
partly at fault for framing it as a question.  I knew quite well that
there was no way to change this behavior for PHP, but wanted to know if
there was perhaps some good reason for why this behavior existed.

I know for my apps how to mitigate the threat of fixation (I think
thanks to an article you wrote), but how many other people know this or
make a habit of doing this (i.e. session id regeneration)?

-Hans

Jared Williams

21 years ago

> >> "why is it this way" should also be posted to the general
> newsgroup,
> >> it barely has anything to do with internals
> >
> >
> > The behavior of the session extension has everything to do with
> > internals. I'm not sure why everyone is sending him to
> php-general. No
> > one there is going to be able to change this behavior. They
> can only
> > suggest userland code to try to work around it.
> >
> > The problem is that PHP uses any user-supplied session
> identifier when
> > creating a new session. This increases the risk of session fixation.
> >
> > If this behavior were changed, it would not completely protect
> > developers from session fixation, but it would be a step in
> the right
> > direction. I think the original poster was making this suggestion.
> >
>
> Thanks, Chris.  Yes, that's what I was suggesting.  I think I
> may be partly at fault for framing it as a question.  I knew
> quite well that there was no way to change this behavior for
> PHP, but wanted to know if there was perhaps some good reason
> for why this behavior existed.
>
> I know for my apps how to mitigate the threat of fixation (I
> think thanks to an article you wrote), but how many other
> people know this or make a habit of doing this (i.e. session
> id regeneration)?

Yes, would be nice to have.

Also having the session cookie sent with the HttpOnly flag, to prevent it getting leaked on supporting client(s)
(IE supports it since 6sp1, mozilla have been discussing implementing it since 2002,
https://bugzilla.mozilla.org/show_bug.cgi?id=178993)  via XSS.
I thought I read sometime back that extending setcookie() was under discussion, to allow for extra settings. Was anything decided?

Jared

Jeremy Johnstone

21 years ago

On Thu, 31 Mar 2005 12:13:22 -0500, Chris Shiflett <shiflett@php.net> wrote:

> The behavior of the session extension has everything to do with
> internals. I'm not sure why everyone is sending him to php-general. No
> one there is going to be able to change this behavior. They can only
> suggest userland code to try to work around it.
>

IMHO, based on what I had read of his email and even upon rereading it
now, he asked "why is it this way" and "is it possible to disable this
behaviour?", both of which are not strictly internals related
questions (although the first could partially be construed that way).
He was not asking for the internals team to change this behaviour
(which of course most of the people on generals would have no ability
to do) so in that case, his question was best asked there, not here
(again IMHO).

--
---------------------------
Jeremy Johnstone
http://www.jeremyjohnstone.com
jsjohnst@php.net

Zeev Suraski

21 years ago

At 19:47 29/03/2005, Hans L wrote:

>Hi,
>
>This may not be the right place for this question, but what I'm looking to
>understand is the reasoning behind what seems to be the standard session
>behavior in PHP.  And, if it's possible, how to change this behavior (via
>INI settings, etc.).
>
>As I understand (and experience) it, if a client [browser] presents a
>session id (e.g. in a cookie) to the server, then PHP will attempt to
>match that ID to the session on the system.  If found, that session
>information will be made available to the scripts.  Fine.  But, if *not
>found* then a new session will be created with the specified ID.
>
>Is there any way to disable this behavior?  I can't think of a single
>circumstance under which this would be the desired behavior, but my use of
>sessions has been more limited to authentication & web applications.

I actually came across one situation where I took advantage of this feature
and relied on it in an application.  It had to do with replicating parts of
a session across a cluster of servers (also for use in authentication).

Zeev

Hans Lellelid

21 years ago

Hi Zeev,

Zeev Suraski wrote:

> At 19:47 29/03/2005, Hans L wrote:
>
>> Hi,
>>
>> This may not be the right place for this question, but what I'm
>> looking to understand is the reasoning behind what seems to be the
>> standard session behavior in PHP.  And, if it's possible, how to
>> change this behavior (via INI settings, etc.).
>>
>> As I understand (and experience) it, if a client [browser] presents a
>> session id (e.g. in a cookie) to the server, then PHP will attempt to
>> match that ID to the session on the system.  If found, that session
>> information will be made available to the scripts.  Fine.  But, if
>> *not found* then a new session will be created with the specified ID.
>>
>> Is there any way to disable this behavior?  I can't think of a single
>> circumstance under which this would be the desired behavior, but my
>> use of sessions has been more limited to authentication & web
>> applications.
>
>
> I actually came across one situation where I took advantage of this
> feature and relied on it in an application.  It had to do with
> replicating parts of a session across a cluster of servers (also for use
> in authentication).
>

Thanks for the response.

Ok, that makes sense.  It seems to be quite a security threat for the
common case of session use, though.  I wonder if this could be a
behavior controlled by a php.ini setting in the future?  I guess what I
originally wanted to ask in my thread is whether there is a well-known
reason for the current behavior or whether I could submit a feature
request that this be changed for upcoming PHP releases.  I think *many*
applications out there would immediately become more secure if session
fixation were not impossible.

Cheers,
Hans

Stefan Esser

21 years ago

Hi Hans,

> common case of session use, though.  I wonder if this could be a
> behavior controlled by a php.ini setting in the future?  I guess what I

well there actually is a way to switch off this behaviour. You can
disable any kind of session fixation attack by adding the line

php_admin_flag engine off

in your httpd.conf

So long
Stefan

ps: If you find any kind of irony in my post, you can keep it...