This one comes via hacker safe regarding one of my sites:
When Zoop sends the PHPSESSID=xxxxxxxxxxx cookie it needs to set the secure attribute in the cookie. Just thought you all should know that this was reported.
To be honest, I'd never heard of this before. I did some research, and here's what it looks like:
When a session is going to be all HTTPS, then the session_set_cookie_params() call should set the secure flag. This will direct the client to only send the cookie when connected through HTTPS.
One thing we can't do (I think) is detect if we are an HTTPS connection, and set the secure flag whenever we are HTTPS. This would mean that a session could not use HTTPS for login, then switch to HTTP for the remainder of the session(which is a common practice when the application data is not important to secure, but the user identity is, such as blogs).
We can however, add support to check the secure flag on our session cookies, notify the user if a secure cookie is being used insecurely and kill the session(so that no eavesdropper can use the session).
We can then add another config directive (maybe session_secure) and use that to determine if the secure flag should be set on cookies. If it's unset, then on HTTPS, we set secure by default, on HTTP we don't by default.
Submitted by jmorant@cloud9l... on Thu, 04/17/2008 - 15:30.
The priority and score of this was very low in hacker safe a 1 out of 5. This ranks it as informational more then anything and does not necessarily designate a vulnerability. There are no other security warnings that come up with regards to Zoop which is excellent since things like SSH version number disclosure can rank as a 2 out of 5. This warning showed up only two days ago after 6 months of security testing so it must be new.
Secure flag
To be honest, I'd never heard of this before. I did some research, and here's what it looks like:
When a session is going to be all HTTPS, then the session_set_cookie_params() call should set the secure flag. This will direct the client to only send the cookie when connected through HTTPS.
One thing we can't do (I think) is detect if we are an HTTPS connection, and set the secure flag whenever we are HTTPS. This would mean that a session could not use HTTPS for login, then switch to HTTP for the remainder of the session(which is a common practice when the application data is not important to secure, but the user identity is, such as blogs).
We can however, add support to check the secure flag on our session cookies, notify the user if a secure cookie is being used insecurely and kill the session(so that no eavesdropper can use the session).
We can then add another config directive (maybe session_secure) and use that to determine if the secure flag should be set on cookies. If it's unset, then on HTTPS, we set secure by default, on HTTP we don't by default.
Does anyone else know anything about this issue?
Priority
The priority and score of this was very low in hacker safe a 1 out of 5. This ranks it as informational more then anything and does not necessarily designate a vulnerability. There are no other security warnings that come up with regards to Zoop which is excellent since things like SSH version number disclosure can rank as a 2 out of 5. This warning showed up only two days ago after 6 months of security testing so it must be new.