Hi! > Other than HTTPS, setting unremovable cookies is easy with JavaScript > vulnerability. Currently, we only has session.use_strict_mode=1. This > is not good enough because attacker can generate valid session ID by
That sound unlikely, given how much space needs to be searched. By the same vein, you could say one could defeat encryption by just guessing the key. Which, if you are unbelievably lucky, can be true, but nobody is that lucky. I don't see how guessing session ID is easier than guessing encryption key. > themselves, and set it to victims cookie. Without session ID > regeneration with precise expiration, attacker may keep logged in > session forever. That's not true, as many application provide session expiration in userspace. > Described how easy to steal session permanently above. It was claimed, but not described how that could actually happen. > Without this proposal, user/web site owner will never know possible > security breach. With this proposal, user/web site owner can detect it > by raised errors for access to expired sessions. I'm not sure what would be the use of it. Suppose you detected somebody is trying to use old sessions to breach your security. Then what? I am also not sure which proposal you refer to that helps with access to expired sessions - aren't they just deleted? If so, you can't distinguish access to expired session from access to one that never existed. > Other than restricting chars for session_id(), this proposal will not > break application. Other possible minor BC happens when apps rely on > constant session ID. Relying on constant session ID is _bad_ practice, > but the patch allows to disable automatic session ID regeneration for > better compatibility. Tests for session behavior may be affected, but > it will not affect production code. Still do not see how restricting chars is beneficial (handlers already restrict what is unacceptable for them). Also, as I said, as a particular implementation detail, I don't think specific session regeneration pattern belongs in core - not all applications would want it, and not all in the same way. Some applications would rather prefer to drop the session and force the user to re-login, for example. > Other than these, user should not have problems in their production > codes. If any, please let me know. Changing defaults and functionality always brings possibility for breakage, and the fact that so many tests needed to be changed also suggests that the applications that would use the same code unmodified would be broken. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
