tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Caron <ca...@unidata.ucar.edu>
Subject Re: session hijacking again
Date Wed, 31 Jan 2007 00:32:07 GMT


Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> John,
> 
> 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
> worries.
> 
> 
>>>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? 

yes, exactly

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.

very cool idea i hadnt thought of

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

yes.


> 
> 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
>    http://securityfilter.sourceforge.net. 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 ;)

I think i see how to get started. Thanks very much!

> 
> Good luck,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFvnWN9CaO5/Lv0PARAvu5AJ9of7roniGwPAN4POlmdwkTcgM9jgCfak7R
> lbMJowQLBIjV/saklBw6gfo=
> =7AMj
> -----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

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


Mime
View raw message