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
|