Jared Farrish wrote:
On 5/29/07, Stut <stuttle@xxxxxxxxx> wrote:
What utter crud. An SSL connection encrypts the whole HTTP conversation,
including headers and even the URL you are requesting. The response is
also encrypted. It doesn't matter whether you're doing a POST or a GET
request, it's all encrypted.
The URL string is encrypted in HTTPS? Well, I was certainly under a
different impression (same with headers). Since I can't say I know any
better beyond a shadow of a doubt, I'll take your word for it. : )
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.
Cookies are no more secure than the session ID. The general conclusion
from many years of discussion in the web community is that the user
experience is diminished so much by not trusting a session ID that the
security improvements are not justified.
So by storing sensitive information in a SESSION, you're safer? Only if the
session doesn't get read... I don't know, I guess in the security sense, it
should be seen as a part of the "conversation" as you put it, so if you
can't trust SESSION, you probably shouldn't use it at all for secure
applications. I still don't see the sense in storing sensitive information
in a session, at least one that persists; if it is passed to a temp
table in
a database and destroyed across calls, I can see that as a better solution,
as long as you have a strong database security configuration.
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.
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.
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.
If you're really concerned then your best bet is to reduce the session
lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
store the user agent in the session and expire it if a request tries to
use an existing session with a different user agent. Unfortunately you
cannot rely on the IP address remaining the same throughout a session,
so don't build that into your session validation.
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.
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.
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?
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
