On 5/29/07, Stut <stuttle@xxxxxxxxx> 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! 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... 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. 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? 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.
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. 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... : ) 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. -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
