When you said:
BDKR wrote:
With the sessions info stored in a database, data used to control the state of a session never need to be sent to the user.
I thought you were saying that the sessionid was not being sent to the client I thought you were implying that writing your own database handlers for session variables was more secure (in terms of network security) than the default file-based method.* But it looks like that's not what you meant.
I'll agree that sending the minimal about of data required for security/tracking is appropriate and that using session variables is better than sending loads of cookies.
However, I'll stand by my view that PHP's session implementation is flawed and insecure. And current versions do not provide a tool for making secure sessions without sending an extra cookie.**
PHP uses the phpsessid value as an
authenticator for tracking state. However it misses three important features:
1. No tamper-detection of the sessionid
2. No tamper-detection of the expiration time
3. No server side checking of the expiration time.
Combined this makes session hijacking and reply attacks trivial. Its possible to send a proper authenticator in a cookie, or in a GET string or where your script compares the PHP passed sessionid with the manually passed sessionid in the authenticator.
*. Yes, on a shared host a database based session handler is more secure from local users than the defaulty bahavoir.
**. Actually I think I might be wrong here. It might be possible to play around with setting session_iid manually. The last time I tried though was in the 4.0.4pl? version, which caused crashes. I should try again and report results. However, will I can add the data needed to make it a good authenticator, I would not be able to "build-in" the proper tamper-detection or server-side expiration without using application code. This means that for 90% or more of the PHP programmers out there, sessions will remain insecure.