# why does PHP accept [new] session ids from client? - Thread: https://externals.io/message/15661 - Original archive: https://news-web.php.net/php.internals/15661 - Started by Hans L on 2005-03-29T17:47:29+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #15661 — Hans L — 2005-03-29T17:47:29+00:00 URL: https://externals.io/message/15661#15661 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 --- ## #15662 — Jeremy Johnstone — 2005-03-29T19:16:11+00:00 URL: https://externals.io/message/15661#15662 · In reply to: #15661 Not to be rude or anything, but this question is better suited for php-general -Jeremy > 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 http://www.jeremyjohnstone.com jsjohnst@php.net --- ## #15663 — Hans L — 2005-03-29T19:34:04+00:00 URL: https://externals.io/message/15661#15663 · In reply to: #15662 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: > Not to be rude or anything, but this question is better suited for php-general > > -Jeremy > > > > > > […] --- ## #15664 — M. Sokolewicz — 2005-03-29T19:39:09+00:00 URL: https://externals.io/message/15661#15664 · In reply to: #15663 "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: > 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: > > > […] --- ## #15701 — Chris Shiflett — 2005-03-31T17:13:22+00:00 URL: https://externals.io/message/15661#15701 · In reply to: #15664 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 --- ## #15702 — Zeev Suraski — 2005-03-31T17:24:46+00:00 URL: https://externals.io/message/15661#15702 · In reply to: #15661 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 --- ## #15704 — Hans Lellelid — 2005-03-31T17:40:22+00:00 URL: https://externals.io/message/15661#15704 · In reply to: #15701 Hi Chris, Chris Shiflett wrote: > M. Sokolewicz 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. > > 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 --- ## #15710 — Jeremy Johnstone — 2005-04-01T02:38:37+00:00 URL: https://externals.io/message/15661#15710 · In reply to: #15701 > 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