Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45BA5B26.8050600@christopherschultz.net>
Date: Fri, 26 Jan 2007 14:48:54 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: session hijacking again
References: <45BA4974.3020902@unidata.ucar.edu>
In-Reply-To: <45BA4974.3020902@unidata.ucar.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

John Caron wrote:
> Our application is serving large amounts of scientific data over HTTP.
> The user needs to login to access the data. We would like to use session
> ids to reduce the login overhead. We cant afford the overhead of HTTPS
> encryption of teh data (3 times slower ?).

I think that SSL is much slower than that. Usually, special hardware is
required to make SSL perform well enough to handle heavy traffic.

> We realize this makes us vulnerable to session hijacking. Still, we
> arent transferring financial information, so tentatively we think its
> a reasonable risk.

<soapbox>
Just make sure that your users don't use the same username and password
they use for their online banking. Seriously. That's the worst part of
all these websites these days that don't use SSL: it's not that the
passwords go in the clear (what do I care if someone hacks into my
NewYorkTimes.com account?), but that most people use the same
credentials for everything, because it's easy. You might want to put a
warning about that on your site.
</soapbox>

> # Some services make secondary checks against the identity of the user.
> For example, a web server could check with each request made that the IP
> address of the user matched the one last used during that session. This
> does not prevent attacks by somebody who shares the same IP address,
> however, and could be frustrating for users who's IP address is liable
> to change during a browsing session.

Like AOL users, and some others going through proxies, etc. It's a
relatively effective mechanism, and you might want to allow users to
opt-in to this type of thing. You'll notice that some sites have a
checkbox in the login form that says "Restrict my session to this
computer", and when that's enabled, you do the IP verification. That
allows AOL (or other) users to opt-out of the security mechanism.

> # Alternatively, some services will change the value of the cookie with
> each and every request. This dramatically reduces the window in which an
> attacker can operate and makes it easy to identify whether an attack has
> taken place, but can cause other technical problems (for example,
> preventing the back button from working properly, on the web).

This is likely to cause problems with the browser getting out of sync
with the server. Also, I'm not sure if you can change the session id in
TC, so you might not be able to do this without a bunch of hacking
around in the TC session code.

> I would like to implement one or both of these in Tomcat: 1) IP checking
> and 2) session id switching. I guess others have thought about this.
> Does anyone have any advice or pointers (or code!) to get started.

What are the implications of session hijacking for your service? Do you
have any trade secrets or anything like that which are considered
sensitive? What about potentially destructive modes of operation -- for
instance, can a user delete or otherwise modify data? If you generally
have read-only data, you might not need to worry too much about session
hijacking.

One other thing you should probably do is reduce the session timeout
from the default of 30 minutes to maybe 5 minutes. You'll close the
window a little more for anyone who is snooping.

Another method that you didn't mention (but that the Wikipedia entry
does mention) is the use of very long session ids. This reduces
guessability of the session id, so someone is very unlikely to, through
dumb luck, guess a currently valid session id. Newer Tomcat versions
(not sure which) allow you to specify the number of characters in the
session id. The default is 16, but I'd imagine that you can go up to
some crazy number like 4096 or something. I don't recommend
4096-character session ids ;)

Without SSL, though, remember that anyone who is capable of hijacking
the session is probably also capable of sniffing your users'
credentials. What are the implications of that? If it is unacceptable to
have your credentials go over the network in cleartext, then you will
simply have to break down and use SSL.

I'm glad to see that someone is actually thinking about security issues
instead of implementing something that sounds good. Nice job, John!

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFulsm9CaO5/Lv0PARAlhHAKCgXuG3hhiHfbsx6aVhgeay3zdjHACaA/aU
1JbkZa2E2HttdagKaFFOCqw=
=tmiH
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org