15 Apr 2008
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.
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.
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.
Update On This Issue
For anyone using Session based zones
After further research on this issue I can more clearly explain the issue. If you are using Session based zones anytime Zoop is run it will causes PHP to send PHPSESSID in a cookie which is standard practice for session management in PHP. This is considered a secure attribute because the browser sends this information back to the server so PHP can reload the session for the user.
In a perfect world no one would use a Session ID that does not belong to them and we would all be happy, but there are some people out there which might abuse this property. Because of this fact it is good programming practice to only send Session IDs across an encrypted connection (HTTPS) for Sessions which contain sensitive user information. There may be times when the Session does not contain sensitive information (For example you are just managing the view state of pages) and you don't want to add sever overhead by using HTTPS and this is OK, but be sure to manage secure and insecure sessions separately with different Session IDs.
With regards to Session based zones the entire session object is stored in the zone so any variables you are using is accessible when the Session is accessed. If you add the line below to any of your zones in the initPage or closePage functions you will see what I mean.
This is NOT a bug, but should exist as a guide to assist in better programming practices when managing session data.
if(isset($_SERVER['HTTPS']))
if(isset($_SERVER['HTTPS'])) echo 'is_secure';
$_SERVER['HTTPS'] will == 'on' when a connection is HTTPS, otherwise will not be set at all.
Edited to add: I shouldn't post on forums late at night. I completely misunderstood what was being said. Oh well.