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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
