Re: Re: a question on session ID and security

Jared Farrish wrote:

On 5/29/07, Stut <stuttle@gmail.com> wrote:

The only part of an SSL connection that's not encrypted is the handshaking that goes on to set it up in the first place. Everything after that, the GET/POST line, headers and the body as well as the entire response is encrypted.

One of these days I'm actually going to run some tests so I can see what is actually happening. I would sound completely ignorant speaking of packets as if I knew them that well, so I won't!

Sniff an SSL connection and you'll see it. Most of the traffic is gibberish!

I never said it was safer to store sensitive information in a session -

stop adding words! All I said was that the whole discussion of session security has been done to death and the conclusion is that you put the minimum possible on the client (the session ID) and store everything else on the server. If security is a big enough issue that you worry about data in the session being read then you need a dedicated server. If on the other hand you mean credit card information when you say sensitive data, there is no reason on earth why that should ever be *stored* anywhere on your server(s), even a "temp" table.

I find the best way to advice people on SESSIONS is not to trust them, and thus not store any kind of sensitive information within them (SSN, credit card, even phone numbers and whatnot). Since I don't happen to use sessions or cookies that often (for this reason), maybe my advice is a little biased. I store user data in cookies...

You do? What sort of data? Nothing sensitive I hope.

One thing that makes this all completely irrevelent is that, for someone with physical access to authenticated browser session (such as an co-worker), no amount of security will prevent misuse of a session.

The best you can hope to provide is end-to-end security and security on the server end. Anything beyond the connection at the client is out of your control and not worth worrying about.

As far as the relative security of cookies against sessions, they are

basically as insecure as each other in most cases, but your cookies are at the mercy of the users setup which is something I'm just not willing to trust.

True. I should have a fallback to use SESSION if cookies are not available, but if I'm doing that, why not go whole-hog?

Fallback to sessions? That makes no sense to me. Aside from the fact that you are storing application data on the client machine (which could be in a library for all you know), you are also transferring all that data for every page request. I really do think you should reconsider this approach.

The bottom line is that anything sent to or received from the user is insecure, and any security that can be added beyond SSL is easily worked around.

And SSL is rendered moot for users who gain browser access to an authenticated session. Security, I believe, is a matter of pushing vulnerabilities into a corner. You can't ever make any system completely secure, as such a system would be virtually useless.

"The only secure computer is one that's never switched on." Can't remember who said that, but it's completely true. However, the essence of a secure web application, for me, lies in not sending anything to the client that the client doesn't need to know about.

Well, if you use COOKIES, you can pass a secondary hash key that can be

used to validate the actual key against a footprint for a visitor (from $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like that's a pretty good way to check against a visitor. I just think it

feels

flimsy to validate a user on a SESSION key only.

Indeed, you can validate a session by using certain information from the $_SERVER array, but bear in mind that none of it is necessarily persistant. I don't know of any examples, but I'm sure somewhere there is a crappy browser that changes its user agent for every request. However, of all the options I think the user agent is your best bet if you really feel you need to worry about it.

What happens if someone is behind a proxy? Never tested that, but if someone were to make a proxy sanitizer that purposefully skewed what it reports in the headers, that approach could be difficult to troubleshoot.

This is precisely my point. At some point you have to ask yourself whether it's worth worrying about? If you're dealing with high-value transactions then you probably need something more akin to a client-server solution than a web-based solution. That way you can control the client-side a lot better than you can in a web-based application.

In your comment above you seem to be suggesting passing that "secondary hash key" between requests via a cookie. Why not just store that in the session? Then it doesn't go outside your app. And as mentioned previously you have a lot more control over the session data than you do over cookie data.

The whole point of using a shared hash is to provide notional benefit by providing a secondary key, that is stored on the browser, which is used to build the authenticated token, which is then matched to the server token. This is a type of security hash similar to the one you suggested above (using $_SERVER variables), only stored in a cookie. Different approach for different folks... : )

It's your choice indeed, but if you built such an application for me I wouldn't accept it because it sends a validation key to the client when the client has absolutely no reason to see that information. Remember that anything that gets transferred between the client and the server is easily modified and cannot be trusted.

Here one final thought... if there was a reliable way to add security to sessions don't you think that one of the multitude of web development languages out there would have done it, including PHP?

I certainly don't think you're implying I thought I had given some new, "better" way of doing sessions that nobody had given before? Curious statement.

No, all I'm saying is that because sessions are a fundamental part of any web development platform, any ideas for securing them that have been made over the years (and there have been many) would have been integrated into the platform-supplied implementation if they were any good. Don't get me wrong, I don't want to discourage anyone from thinking about ways to improve it, but personally I consider this issue done to death. -Stut