Hi! > Because current session module cannot distinguish if session ID come > from outside, i.e. session cookie/trans sid, or script. This could be > improved, but user should control session.use_strice_mode currently.
I think quite the opposite - user's shouldn't change stict_mode settings in runtime. > I realized that accessible magic values in $_SESSION were unpopular > from discussions. I proposed minimum change also and It was declined. I know the RFC was declined, but RFC was huge and changed a lot of things. I propose a very small and limited change on which we can build incrementally. > Differences are, it hides timestamp from $_SESSION, timestamp is only > viewable via API. I don't think we need to hide things, really. Why hide it? > Unprecise > - Cannot make sure obsolete session removal. > - Accessibility to obsolete session is controlled by GC. (Attackers > can keep it alive by simply accessing it) Since that session is marked as deleted, you can easily reject it. So it doesn't matter if it's kept alive or not. > Unsecure > - No way to detect possible session hijack. (My last proposal omit > raising error because people seem to care about BC too much rather > than security. Adding error/exception is matter of few lines) I think you are confusing here "insecure" (allows privilege escalation, unauthorized access, etc.) and "does not allow detection for particular attack". I'm not sure what this does with session hijack at all - if somebody hijacked your session, how would you detect it with session_regenerate_id()? I don't think this function has anything to do with attack detection, and in general attack detection is not what session mechanism is really for. If somebody got hold of your authenticated session ID, it's pretty much game over for you, unless you have protections like IP-control, etc. which are beyond the scope of current discussion. I think one of the reasons the previous RFC failed is that you tried to do a lot of different and very tangentially related things at once. Let's not do that again. > Timestamp based management is mandatory for precise/secure session management. You keep repeating this but just repeating this doesn't add much to the discussion. I think everybody is aware of your opinion by now, and simply repeating it again and again does not add much. Let's proceed to more specific arguments. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
