Jared Farrish wrote:
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!
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
