Thread

Simple question this (I hope)! How secure is the session cookie that tracks the user’s ID and so forth?

Does EE encrypt it and validate it’s still OK when reloading it or are we relying on the user not doing something naughty with it and changing their userID or even groupID?

smidoid, when you turn on sessions you’ll always see a Session ID in the URL - as you can see, that is not just plain text information.

Can you clarify what you are concerned about?

Thank you.

Hi Lisa,

(It’s Marc, BTW) 😉

Here’s the problem. Assume that Joe Hacker comes along and decides to fool around with some data I have cached in the cookie/session - unless there’s a secure hash or encryption making sure that data is in the same state I left it, it’s a great way to fool the backend into doing something it shouldn’t.

For instance the $SESS cookie, IIRC, stores things like the users ID and group ID, but if this is only plain text someone could elevate their groupID or change their userID to a number of their choosing, and thererfore spoof the engine into doing something it shouldn’t, could they not?

Normal users won’t do this of course and so far all I’m actually caching is only “display” information to save reading it back from the database but it struck me that some of the EE values are also stored in a session: for the same reason.

(George Schlossnagle discusses this at length in his book Advanced PHP Programming (http://www.amazon.com/exec/obidos/tg/detail/-/0672325616/) which is one of my bibles.)

EDIT: Lisa - I don’t see a session ID in the URL Firefox or Safari - is this a feature of those browsers? I can’t test Windows based browsers since I develop on a Mac!

Marc, EE’s cookies do not save unencrypted info that you could simply edit. There’s a userhash, unique_id, expiration date, session_id and a few other values, but in all important cases this is only a reference to data stored in the database. This is not a security issue.

You can configure whether to use a session_id in addition to a cookies. This feature is available regardless of the browser you are using.

So it looks like EE’s cookies are OK (no surprise there!) but I’ll have to encrypt the odd little bits that I need to keep secure.

(Seems a little pointless having information in a cookie if I have to validate the hash against the table every time the table is refreshed.)

Another question answered. Now that’s what I CALL service.

😉

What “odd bits” are you talking about? Is this some custom data? If so, yes, you’d be responsible for such a cookie. My suggestion would be to use EE custom fields (or perhaps member profile fields) and let EE handle it.

I’d love to, but I don’t have that option unfortunately.

For example, some of my custom fields are numeric (ints and floats) which are not supported in the current incarnation: unless I missed something. Plus I need to access them in very particular ways. My application goes well beyond what EE was intended for - BUT it’s making an excellent launchpad.

(Incidentally, looking at the security hash table - EE seems to be generating a lot of unused space in the table: nearly 50% overhead so far - presumably this is a MySQL problem with the garbage collection.)

My biggest “issue” although this is OT for this thread, is handling forms. I need to post-load (using AJAX) some bits of the page (including EE generated ones) back into my “skin”. I can PM you the working site in progress if you wanted to see what I mean by this.

Very well, I’ll just assume you know what you’re doing 😊 But yes, EE’s cookies should be safe and secure. Please don’t hesitate to post again as needed.