Hi! > I would like to restart better session management for PHP 7.1. > > https://wiki.php.net/rfc/precise_session_management
I've read the RFC and I have some questions and comments: 1. I do not see why old session being active is a problem when you regenerate. You write "Attacker may abuse stolen session forever." - I'm not sure what abuse is meant. If the old session was unauthenticated, then you can not abuse it in any meaningful way. If the old session was authenticated, then a) you already lost b) regenerate is not needed, since regenerate happens when crossing security border and c) sessions can expire, so it won't be forever anyway, unless you maintain it, but even then application can easily implement limit on session length in userspace. 2. I do not see why you need to know specifically when the session is deleted. Also, I'm not sure what you mean by "invalid session". 3. "Stealing session ID is easy regardless of HTTPS" - I certainly disagree with this. Is that were easy, every application in PHP using sessions for authentication (which is close to all of them ever using authentication) would be trivially vulnerable. As I do not see any reports of such mass security failure happening, it must not be as easy as you claim. Also, "search the internet to find the proof of what I am saying" is not a good argument in an RFC. It's your argument, so it's your job to search the internet and present the proof. If it's very easy, then it should not even take long. 4. The bugs you quote are: - 69127 - unclear what is going on there, but looks like you understand what is going on, could you explain on the bug or here? - 68063 - easily fixable by rejecting empty ID< but it is a trivial matter, since practical importance of this seems to be nil - 70584 - unclear what is going on here, but doesn't seem to be related to anything discussed above, at least. Maybe caused by the new code, according to 70013 They are from 2015 and 2014, so I don't see how any of these are "known more than 10 years" - could you explain what you mean by that? 5. I don't like magic session variables too much, though if they will be implemented transparently from the user, it might be ok. 6. Session TTLs are very dependent on application nature - for some, it's ok to have sessions live nearly forever, for others, sessions may live only minutes. Also, some applications may count it from session start, others from session last use, others have more complex criteria. Trying to do one-fits-all solution is not good here. While having the date when session was initiated may be useful and would not be hurtful for most scenarios, messing with sessions - such as deleting them - when app developer does not expect it may not be a good idea. 7. Not sure I understand what ttl_update is for. If we already have last access time (which we already do, AFAIK) and session start time (which is your proposal) - why do we need anything else? 8. "Therefore, there should be GC API for cron task for instance." - I am not sure what are you meaning here. Could you describe the scenario where such function would be useful and how exactly would it be used? What people that do not have cron functionality or access to it should do? 9. "Raise error/exception for invalid access" - I do not think it is clear what is "invalid access". Does it mean access with non-existing session ID would raise an error? That would definitely break almost every application using sessions (since now they all rely on PHP treating expired session the same as if there were no session, thus triggering standard "not authenticated" workflow). I think this RFC needs a bit more work now to clarify those points. Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
