On 01/22/2011 01:39 PM, Camaleón wrote:
I wish I had.. sessions carried at server side, hidden fields in forms or
variable uri encoding were the common methods used in the past.
I don't think you've fully understood the problem. The problem is not
that cookies contain sensitive data (well, some do), but rather that
even just a session ID - which can be just a random number with no
meaning other than identifying in the server data related to that user,
even if has nothing sensitive, can be used to hijack the session if
another uses gets hold of that ID, depending on how the server side is
implemented. Several sites fall to this attack (as FireSheep shows). I
confess I don't have a good solution on how to solve that in the server
side.
If traffic is unencrypted (http), then it's easy to capture session IDs.
SSL prevents that, even if someone can sniff the traffic, all they get
is random garbage. (At least in theory, but I don't know of any real
attack on SSL.)
That's the same reason I was advocating that people should not leave
Wi-Fi (even if public) unencrypted. If traffic is unencrypted, it is
trivial for anyone to capture session IDs flying in plain text through
the air. If the network is encrypted, then it is much harder to capture
other people's traffic. (Should be impossible, but there are attacks.
But things are much more difficult.)
Cookies are insecure by their own nature and fail to provide a proven
mechanism for uniquely identifying users. You can "hide" (by encrypting
the file) the content of the cookie and you'll avoid remote side
hijacking when someone is sniffing the connection, but the root of
problem still remains: should the "hijacker" has physical access to the
computer I guess he can also impersonate the login session (someone in
the know may want to correct this statement).
Or just think about removable flash drive devices with portable versions
of the browsers; the owner logins into his online account (facebook,
gmail, whatever...), check the "remember me" option and keeps the full
session encrypted via https (not just the login part). Another user with
access to the flash drive could copy the whole content of the data and re-
use (hijack) the cookie that holds the session id.
Well, if someone has physical access to the hardware, it's game over.
They can do everything with it. Encrypting the contents of the HD can
limit somewhat what someone can do, though.
What I was trying to expose here is that http is a protocol designed
mostly for single-user sessions [...]
Maybe is just we are not using the "right" tool for the job...
I'd agree, but I don't see things changing any time soon. Just see the
status of IPv6 transition: IPv4 addresses are running out, and yet very
few people are bothering to switch for IPv6. The same will happen: even
if a new protocol is proposed, browsers won't rush to support it because
no sites will be using it, and no sites will use it because few browsers
support the new protocol.
--
1 + 1 = 3, for large values of 1.
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d3b145e.2090...@kalinowski.com.br