> >> "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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
