Question : Session

[paulocmguerreiro]

While adding last_activity update in Session class, this following two function seemed strange:

Session:newSession()
-Isn't there a possibility that randstr could create an already existing session_id, it could trigger a collision?

Session:existingSession()
-This function is blindly believing in $_COOKIE["SESSIONID"], is it not better to store some additional info with the session (IP, USERAGENT, ...) to try to mitigate Session/Cookie Hijacking?

What do you guys think?

[SvenRtbg]

As long as there is issue #69 open, the generated session ids are sort of predictable anyway.

But then: The IP address should not go into anything - this information is designed to change over time. The user agent? Probably a valid info, but also not very secret - if I would be an attacker, I would try to copy the original request as closely as possible.

Session security is most impacted by predictable session ids. And insecure unencrypted communication.

[rash805115]

The program is not blindly believing in COOKIE variable. If you will see, the sessions are being checked in DB itself, whether its a valid sessionID or not.

[paulocmguerreiro]

@SvenRtbg i guess it wont be that easy to solve then!?

@rash805115 I did not explained correctly. When i said it was blindy believing (i know the the session_id is verified in the db), i was referring that if the cookie was hijacked theres was no other information to know if it was stolen, i suggested (IP and USERAGENT). From what SvenRtbg wrote it isn't also a viable solution as it can be tampered.