tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Caron <>
Subject Re: session hijacking again
Date Mon, 29 Jan 2007 20:08:50 GMT
Hi Christopher:

Christopher Schultz wrote:
> 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.

A recent paper estimated 3-9X slower, but for my problem (large binary file transfer) Im guessing
2-3X for fast CPUs. That paper, BTW, suggests that faster general CPUs are the way to go vs
specialized hardware.

Performance Analysis of TLS Web Servers
ACM Transactions on Computer Systems, Vol. 24, No. 1, February 2006.

>>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
> 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>

We plan on using SSL to do the initial authentication, but then use session ids without SSL
for the data transfer.

>># 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.

Hmm I didnt know that about "opt-out" security. We arent really doing web sites, we are enabling
data access by scientific programs. 

>># 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.

yeah, im thinking i prefer the IP check, since our users tend to not be dialup. But Im wondering
if i will have to "hack around" the tomcat code to do IP checking.

>>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.

Its read-only, and no trade secrets or $$ involved. So im not convinced we even need to worry
about session hijacking, but i'd like to know what are options are.

> 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.

good idea, thanks.

> 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!

thanks, but i havent done anything yet!

i appreciate you time in thinking about this issue.


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message