-----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? 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 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 ;) 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]
