cookies for sessions
so i set about using cookies and got it all finished and wrapped up in a bow when someone else suggested that the script could be hacked with 'cross site scripting' or something or other.
my question is, how hackable are these cookies?
I'm generating the Session ID the way i always did, uniquid() md5'd and base64 encoded to give me a nice random string of digits, i then store this under the user's name in the database (like i always did) and then fired out a cookie containing this Session ID but no longer pass it to a variable at the end of a URL.
To stay logged in the user's session id in the cookie must match the one stored in the database; URLs containing a Session ID for a user will no longer get them into their account unless they have the cookie.
Is this hackable?
There are (some) pages which append the session id to the url which i'm working on cleaning at the moment, but the only hacking opportunity i can see is if a user were to create a cookie (as a text file maybe?) and paste in the target's session id.
Are you using a custom session handler or the one built in to PHP? Usually as long as you regenerate the session any time the level of access changes you are secure enough. You also should make sure not to store any username/password combos in the session itself. In my opinion it is more secure and less likely to have session fixation when using cookies rather than appending the string to the url.
i'm not storing login credentials in the session, but yes it's a custom handler, the php one wouldn't work with what i'm using it for unfortunately.
Originally Posted by criterion9
what do you mean by 'when the level of access changes'? you mean like different areas of the site or when a user logs in again?
Like start a new session is a user gets admin access, or logs out.
What do you mean by that?
yes it's a custom handler, the php one wouldn't work with what i'm using it for unfortunately.
i generate a session id based on..
Originally Posted by criterion9
a uniquid() and a base64() of the user agent & ip address, those are both thrown into an md5 hash which is then truncated to 16 characters, strtoupper()'d and thrown into a cookie and into the database (to compare the cookie against, if it's changed, the session is invalid).
You can use the built in session handlers with your own custom session ids. I have never found a good enough reason to try to handle the cookie process in place of letting PHP do the job (though I have changed the storage method to use a database instead to allow for load balancing).
FWIW, I've always just used the built-in session cookie/ID generation via session_start() (and session_regenerate_id() when desired), and when wanted in conjunction with a database-driven custom session data handler, e.g.: http://www.charles-reace.com/blog/20...ssion-handler/.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)