tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: session hijacking again
Date Mon, 29 Jan 2007 22:30:37 GMT
Hash: SHA1


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

Okay, thanks for clarifying that. This is definitely a good thing to do,
and it appears that session hijacking /will/ then be one of your only

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

Oh, okay. So, you have something like an XML-based web service or
something like that? You could offer a standard configuration for your
customers (which uses IP checks) and then provide instructions to users
for whom this poses a problem to disable this checking. Make the
"configurability" of this feature part of the login request (i.e. add an
optional parameter like verifyIPAddress=true|false) so that it cannot be
changed after login to subvert your protection.

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

Not at all. You have a few options:

1. Write a filter, applied to all URLs, that checks for a session
   flag -- something like "verifyIPAddress" -- which is the IP address
   of the user who logged-in. If the IP for the request != login IP,
   then do something simple like sendError(FORBIDDEN) or whatever.
   This is probably the easiest thing to do. Of course, you will have
   to put this session attribute into the session at some point, which
   is somewhat problematic since if you use container-managed logins,
   you never know when the login takes place. Are you using
   container-managed logins?

2. You can replace the authenticator and authorization system with
   something else. I routinely recommend securityfilter, which is
   an Open Source project ans can be found at You can customize many
   parts of the login process, including what happens during and
   after login -- including something like setting a session
   attribute to turn on (or off) IP checking.

   You can also build IP checking into the additional code you write
   for authorization.

   Needless to say, this is more complex, but gives you greater
   control over the process.

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

I think that after your investigation, you may find that spending a lot
of time preventing session hijacking is simply not worth it.

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

Actually, that's the point: most people start "doing" before they have
finished /thinking/. You are at least doing things in the proper order ;)

Good luck,
- -chris
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message