You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Caron <ca...@unidata.ucar.edu> on 2007/01/26 19:33:24 UTC
session hijacking again
Hello:
Our application is serving large amounts of scientific data over HTTP. The user needs to login to access the data. We would like to use session ids to reduce the login overhead. We cant afford the overhead of HTTPS encryption of teh data (3 times slower ?). We realize this makes us vulnerable to session hijacking. Still, we arent transferring financial information, so tentatively we think its a reasonable risk.
The Wikipedia article (http://en.wikipedia.org/wiki/Session_hijacking) suggest a couple of things that help, that seem reasonable to me:
# Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users who's IP address is liable to change during a browsing session.
# Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, preventing the back button from working properly, on the web).
I would like to implement one or both of these in Tomcat: 1) IP checking and 2) session id switching. I guess others have thought about this. Does anyone have any advice or pointers (or code!) to get started.
Thanks for any help.
John Caron
Unidata/UCAR
---------------------------------------------------------------------
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
Re: session hijacking again
Posted by Pid <p...@pidster.com>.
Martin Gainty wrote:
> John and Peter
>
> SE seems definitely O/T so please email me offline on this topic of Social Engineering..Perhaps this is a project which the government never discloses?
> Admittedly I have no information as to the definition and or implications of such a plan
eh?
> Thanks,
> Martin--
> ---------------------------------------------------------------------------
> This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited.
> ---------------------------------------------------------------------------
> Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire.
> ----- Original Message -----
> From: "John Caron" <ca...@unidata.ucar.edu>
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Sent: Monday, January 29, 2007 3:17 PM
> Subject: Re: session hijacking again
>
>
>> Hi Peter:
>>
>> Peter Stavrinides wrote:
>>> Do you use Java?
>> yes
>>
>>> We are a financial institution, we use a Java Framework based on
>>> servlets with SSL, but if you ask my opinion SSL is not the big issue.
>>> The vast majority of hacked sites are social engineering attacks. Secure
>>> your database (do not store clear text passwords in the database)
>>> minimize access of staff, require strong passwords (8 characters and
>>> numbers). No strategy or amount of code is foolproof, although yes It is
>>> also worth the extra effort to make your application a bit smart, but it
>>> is better to focus your attention on preventing social engineering,
>>> because no matter how clever you make it if the passwords are easily
>>> guessed or users careless its all for nothing.
>>>
>>> Design your application like a container that reloads its body, that way
>>> you can implement security and logging application wide with minimal code.
>>>
>>> We secure our application like this: on login (after authentication) we
>>> store in state for the duration of that session, the users unique id and
>>> session id and for logging purposes the current IP. (no cookies etc are
>>> used at all, because cookies are stored on the client which is out of
>>> our control).
>> doesnt the client have to return a jsessionid cookie?
>>
>>> We perform a check for each new login to ensure at least the user id and
>>> session id does NOT exist in state before allowing the new login. We do
>>> not allow two concurrent logins with the same account.
>>>
>>> If you wish to implement session id switching you have to destroy the
>>> users old session and recreate it and update the session id in state (to
>>> me again, just my humble opinion, not so important)... it is far more
>>> useful to use a session timer that times out after a few minutes of
>>> inactivity, it will automatically call a sign out but you can keep the
>>> users details in the server state until the browser closes, if they try
>>> to continue activity, then you ask them to sign in again and add their
>>> new session id back into your state object. When the browser closes a
>>> session listener cleans out the session so the users details are discarded.
>>>
>>> Again paranoid coding is not going to prevent social engineering,
>>> educating users might... by far the most effective strategy is to tell
>>> users to never give out their password, give them a support number and
>>> inform them about what the support personnel is and isn't allowed to ask
>>> them for. Lastly tell users exactly what type of email they will and
>>> won't receive from your organization. When they login to your site tell
>>> them they should ALWAYS check that the domain name appears correctly in
>>> the address bar.
>> thank you very much for your advice, i will use it!
>>
>> John
>>
>> ---------------------------------------------------------------------
>> 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
Re: session hijacking again
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin,
Martin Gainty wrote:
> SE seems definitely O/T
This is not off-topic.
> so please email me offline on this topic of Social Engineering
This is not a question about social engineering.
> Perhaps this is a project which the government never discloses?
??!
> Admittedly I have no information as to the definition and or
> implications of such a plan
Then why are you responding?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFv4eu9CaO5/Lv0PARAhz4AJ9LN8c/MEh1da1OsP48gk5Ek0fptACeNXRD
qKPJzbN26deSOQknAsZYIgg=
=7s7r
-----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
Re: session hijacking again
Posted by Martin Gainty <mg...@hotmail.com>.
John and Peter
SE seems definitely O/T so please email me offline on this topic of Social Engineering..Perhaps this is a project which the government never discloses?
Admittedly I have no information as to the definition and or implications of such a plan
Thanks,
Martin--
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited.
---------------------------------------------------------------------------
Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire.
----- Original Message -----
From: "John Caron" <ca...@unidata.ucar.edu>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Monday, January 29, 2007 3:17 PM
Subject: Re: session hijacking again
> Hi Peter:
>
> Peter Stavrinides wrote:
>> Do you use Java?
>
> yes
>
>>
>> We are a financial institution, we use a Java Framework based on
>> servlets with SSL, but if you ask my opinion SSL is not the big issue.
>> The vast majority of hacked sites are social engineering attacks. Secure
>> your database (do not store clear text passwords in the database)
>> minimize access of staff, require strong passwords (8 characters and
>> numbers). No strategy or amount of code is foolproof, although yes It is
>> also worth the extra effort to make your application a bit smart, but it
>> is better to focus your attention on preventing social engineering,
>> because no matter how clever you make it if the passwords are easily
>> guessed or users careless its all for nothing.
>>
>> Design your application like a container that reloads its body, that way
>> you can implement security and logging application wide with minimal code.
>>
>> We secure our application like this: on login (after authentication) we
>> store in state for the duration of that session, the users unique id and
>> session id and for logging purposes the current IP. (no cookies etc are
>> used at all, because cookies are stored on the client which is out of
>> our control).
>
> doesnt the client have to return a jsessionid cookie?
>
>>
>> We perform a check for each new login to ensure at least the user id and
>> session id does NOT exist in state before allowing the new login. We do
>> not allow two concurrent logins with the same account.
>>
>> If you wish to implement session id switching you have to destroy the
>> users old session and recreate it and update the session id in state (to
>> me again, just my humble opinion, not so important)... it is far more
>> useful to use a session timer that times out after a few minutes of
>> inactivity, it will automatically call a sign out but you can keep the
>> users details in the server state until the browser closes, if they try
>> to continue activity, then you ask them to sign in again and add their
>> new session id back into your state object. When the browser closes a
>> session listener cleans out the session so the users details are discarded.
>>
>> Again paranoid coding is not going to prevent social engineering,
>> educating users might... by far the most effective strategy is to tell
>> users to never give out their password, give them a support number and
>> inform them about what the support personnel is and isn't allowed to ask
>> them for. Lastly tell users exactly what type of email they will and
>> won't receive from your organization. When they login to your site tell
>> them they should ALWAYS check that the domain name appears correctly in
>> the address bar.
>
> thank you very much for your advice, i will use it!
>
> John
>
> ---------------------------------------------------------------------
> 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
>
>
Re: session hijacking again
Posted by John Caron <ca...@unidata.ucar.edu>.
Hi Peter:
Peter Stavrinides wrote:
> Do you use Java?
yes
>
> We are a financial institution, we use a Java Framework based on
> servlets with SSL, but if you ask my opinion SSL is not the big issue.
> The vast majority of hacked sites are social engineering attacks. Secure
> your database (do not store clear text passwords in the database)
> minimize access of staff, require strong passwords (8 characters and
> numbers). No strategy or amount of code is foolproof, although yes It is
> also worth the extra effort to make your application a bit smart, but it
> is better to focus your attention on preventing social engineering,
> because no matter how clever you make it if the passwords are easily
> guessed or users careless its all for nothing.
>
> Design your application like a container that reloads its body, that way
> you can implement security and logging application wide with minimal code.
>
> We secure our application like this: on login (after authentication) we
> store in state for the duration of that session, the users unique id and
> session id and for logging purposes the current IP. (no cookies etc are
> used at all, because cookies are stored on the client which is out of
> our control).
doesnt the client have to return a jsessionid cookie?
>
> We perform a check for each new login to ensure at least the user id and
> session id does NOT exist in state before allowing the new login. We do
> not allow two concurrent logins with the same account.
>
> If you wish to implement session id switching you have to destroy the
> users old session and recreate it and update the session id in state (to
> me again, just my humble opinion, not so important)... it is far more
> useful to use a session timer that times out after a few minutes of
> inactivity, it will automatically call a sign out but you can keep the
> users details in the server state until the browser closes, if they try
> to continue activity, then you ask them to sign in again and add their
> new session id back into your state object. When the browser closes a
> session listener cleans out the session so the users details are discarded.
>
> Again paranoid coding is not going to prevent social engineering,
> educating users might... by far the most effective strategy is to tell
> users to never give out their password, give them a support number and
> inform them about what the support personnel is and isn't allowed to ask
> them for. Lastly tell users exactly what type of email they will and
> won't receive from your organization. When they login to your site tell
> them they should ALWAYS check that the domain name appears correctly in
> the address bar.
thank you very much for your advice, i will use it!
John
---------------------------------------------------------------------
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
Re: session hijacking again
Posted by Peter Stavrinides <p....@albourne.com>.
Do you use Java?
We are a financial institution, we use a Java Framework based on
servlets with SSL, but if you ask my opinion SSL is not the big issue.
The vast majority of hacked sites are social engineering attacks. Secure
your database (do not store clear text passwords in the database)
minimize access of staff, require strong passwords (8 characters and
numbers). No strategy or amount of code is foolproof, although yes It is
also worth the extra effort to make your application a bit smart, but it
is better to focus your attention on preventing social engineering,
because no matter how clever you make it if the passwords are easily
guessed or users careless its all for nothing.
Design your application like a container that reloads its body, that way
you can implement security and logging application wide with minimal code.
We secure our application like this: on login (after authentication) we
store in state for the duration of that session, the users unique id and
session id and for logging purposes the current IP. (no cookies etc are
used at all, because cookies are stored on the client which is out of
our control).
We perform a check for each new login to ensure at least the user id and
session id does NOT exist in state before allowing the new login. We do
not allow two concurrent logins with the same account.
If you wish to implement session id switching you have to destroy the
users old session and recreate it and update the session id in state (to
me again, just my humble opinion, not so important)... it is far more
useful to use a session timer that times out after a few minutes of
inactivity, it will automatically call a sign out but you can keep the
users details in the server state until the browser closes, if they try
to continue activity, then you ask them to sign in again and add their
new session id back into your state object. When the browser closes a
session listener cleans out the session so the users details are discarded.
Again paranoid coding is not going to prevent social engineering,
educating users might... by far the most effective strategy is to tell
users to never give out their password, give them a support number and
inform them about what the support personnel is and isn't allowed to ask
them for. Lastly tell users exactly what type of email they will and
won't receive from your organization. When they login to your site tell
them they should ALWAYS check that the domain name appears correctly in
the address bar.
John Caron wrote:
> Hello:
>
> Our application is serving large amounts of scientific data over HTTP.
> The user needs to login to access the data. We would like to use
> session ids to reduce the login overhead. We cant afford the overhead
> of HTTPS encryption of teh data (3 times slower ?). We realize this
> makes us vulnerable to session hijacking. Still, we arent transferring
> financial information, so tentatively we think its a reasonable risk.
>
> The Wikipedia article (http://en.wikipedia.org/wiki/Session_hijacking)
> suggest a couple of things that help, that seem reasonable to me:
>
> # Some services make secondary checks against the identity of the
> user. For example, a web server could check with each request made
> that the IP address of the user matched the one last used during that
> session. This does not prevent attacks by somebody who shares the same
> IP address, however, and could be frustrating for users who's IP
> address is liable to change during a browsing session.
>
> # Alternatively, some services will change the value of the cookie
> with each and every request. This dramatically reduces the window in
> which an attacker can operate and makes it easy to identify whether an
> attack has taken place, but can cause other technical problems (for
> example, preventing the back button from working properly, on the web).
>
> I would like to implement one or both of these in Tomcat: 1) IP
> checking and 2) session id switching. I guess others have thought
> about this. Does anyone have any advice or pointers (or code!) to get
> started.
>
> Thanks for any help.
>
> John Caron
> Unidata/UCAR
>
> ---------------------------------------------------------------------
> 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
>
--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail.
---------------------------------------------------------------------
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
Re: session hijacking again
Posted by John Caron <ca...@unidata.ucar.edu>.
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
Re: session hijacking again
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: session hijacking again
Posted by John Caron <ca...@unidata.ucar.edu>.
Hi Christopher:
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John,
>
> John Caron wrote:
>
>>Our application is serving large amounts of scientific data over HTTP.
>>The user needs to login to access the data. We would like to use session
>>ids to reduce the login overhead. We cant afford the overhead of HTTPS
>>encryption of teh data (3 times slower ?).
>
>
> I think that SSL is much slower than that. Usually, special hardware is
> required to make SSL perform well enough to handle heavy traffic.
A recent paper estimated 3-9X slower, but for my problem (large binary file transfer) Im guessing 2-3X for fast CPUs. That paper, BTW, suggests that faster general CPUs are the way to go vs specialized hardware.
Performance Analysis of TLS Web Servers
CRISTIAN COARFA, PETER DRUSCHEL, and DAN S. WALLACH, Rice University
ACM Transactions on Computer Systems, Vol. 24, No. 1, February 2006.
>
>
>>We realize this makes us vulnerable to session hijacking. Still, we
>>arent transferring financial information, so tentatively we think its
>>a reasonable risk.
>
>
> <soapbox>
> Just make sure that your users don't use the same username and password
> they use for their online banking. Seriously. That's the worst part of
> all these websites these days that don't use SSL: it's not that the
> passwords go in the clear (what do I care if someone hacks into my
> NewYorkTimes.com account?), but that most people use the same
> credentials for everything, because it's easy. You might want to put a
> warning about that on your site.
> </soapbox>
We plan on using SSL to do the initial authentication, but then use session ids without SSL for the data transfer.
>
>># Some services make secondary checks against the identity of the user.
>>For example, a web server could check with each request made that the IP
>>address of the user matched the one last used during that session. This
>>does not prevent attacks by somebody who shares the same IP address,
>>however, and could be frustrating for users who's IP address is liable
>>to change during a browsing session.
>
>
> 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.
>
>
>># Alternatively, some services will change the value of the cookie with
>>each and every request. This dramatically reduces the window in which an
>>attacker can operate and makes it easy to identify whether an attack has
>>taken place, but can cause other technical problems (for example,
>>preventing the back button from working properly, on the web).
>
>
> 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.
>
>
>>I would like to implement one or both of these in Tomcat: 1) IP checking
>>and 2) session id switching. I guess others have thought about this.
>>Does anyone have any advice or pointers (or code!) to get started.
>
>
> 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.
>
> One other thing you should probably do is reduce the session timeout
> from the default of 30 minutes to maybe 5 minutes. You'll close the
> window a little more for anyone who is snooping.
good idea, thanks.
>
> Another method that you didn't mention (but that the Wikipedia entry
> does mention) is the use of very long session ids. This reduces
> guessability of the session id, so someone is very unlikely to, through
> dumb luck, guess a currently valid session id. Newer Tomcat versions
> (not sure which) allow you to specify the number of characters in the
> session id. The default is 16, but I'd imagine that you can go up to
> some crazy number like 4096 or something. I don't recommend
> 4096-character session ids ;)
>
> Without SSL, though, remember that anyone who is capable of hijacking
> the session is probably also capable of sniffing your users'
> credentials. What are the implications of that? If it is unacceptable to
> have your credentials go over the network in cleartext, then you will
> simply have to break down and use SSL.
>
> 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!
i appreciate you time in thinking about this issue.
John.
---------------------------------------------------------------------
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
Re: session hijacking again
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mitchell,
Fisher, Mitchell L wrote:
>> Without SSL, though, remember that anyone who is capable of hijacking
>> the session is probably also capable of sniffing your users'
>> credentials. What are the implications of that? If it is unacceptable
> to
>> have your credentials go over the network in cleartext, then you will
>> simply have to break down and use SSL.
>
> How practical is it to use NTLM authentication w/ Tomcat?
I dunno.
> And if not NTLM, then Digest Authentication, while not as strong as
> NTLM, is supported by Tomcat. Either prevents transmission of
> credentials in clear text.
Fair enough, but John already pointed out that he will be using SSL for
the login process, even though they do not use SSL for the user's entire
session.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFv/N19CaO5/Lv0PARAv0yAJ4rhd4nUkyu0k9MOoBXcd9VyKDYQQCgs8u1
0HCzlbPYGP+4Q102PCRU3z4=
=uND5
-----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
RE: session hijacking again
Posted by "Fisher, Mitchell L" <Mi...@unisys.com>.
> Without SSL, though, remember that anyone who is capable of hijacking
> the session is probably also capable of sniffing your users'
> credentials. What are the implications of that? If it is unacceptable
to
> have your credentials go over the network in cleartext, then you will
> simply have to break down and use SSL.
How practical is it to use NTLM authentication w/ Tomcat? And if not
NTLM, then Digest Authentication, while not as strong as NTLM, is
supported by Tomcat. Either prevents transmission of credentials in
clear text.
Mitchell Fisher
---------------------------------------------------------------------
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
Re: session hijacking again
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
John Caron wrote:
> Our application is serving large amounts of scientific data over HTTP.
> The user needs to login to access the data. We would like to use session
> ids to reduce the login overhead. We cant afford the overhead of HTTPS
> encryption of teh data (3 times slower ?).
I think that SSL is much slower than that. Usually, special hardware is
required to make SSL perform well enough to handle heavy traffic.
> We realize this makes us vulnerable to session hijacking. Still, we
> arent transferring financial information, so tentatively we think its
> a reasonable risk.
<soapbox>
Just make sure that your users don't use the same username and password
they use for their online banking. Seriously. That's the worst part of
all these websites these days that don't use SSL: it's not that the
passwords go in the clear (what do I care if someone hacks into my
NewYorkTimes.com account?), but that most people use the same
credentials for everything, because it's easy. You might want to put a
warning about that on your site.
</soapbox>
> # Some services make secondary checks against the identity of the user.
> For example, a web server could check with each request made that the IP
> address of the user matched the one last used during that session. This
> does not prevent attacks by somebody who shares the same IP address,
> however, and could be frustrating for users who's IP address is liable
> to change during a browsing session.
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.
> # Alternatively, some services will change the value of the cookie with
> each and every request. This dramatically reduces the window in which an
> attacker can operate and makes it easy to identify whether an attack has
> taken place, but can cause other technical problems (for example,
> preventing the back button from working properly, on the web).
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.
> I would like to implement one or both of these in Tomcat: 1) IP checking
> and 2) session id switching. I guess others have thought about this.
> Does anyone have any advice or pointers (or code!) to get started.
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.
One other thing you should probably do is reduce the session timeout
from the default of 30 minutes to maybe 5 minutes. You'll close the
window a little more for anyone who is snooping.
Another method that you didn't mention (but that the Wikipedia entry
does mention) is the use of very long session ids. This reduces
guessability of the session id, so someone is very unlikely to, through
dumb luck, guess a currently valid session id. Newer Tomcat versions
(not sure which) allow you to specify the number of characters in the
session id. The default is 16, but I'd imagine that you can go up to
some crazy number like 4096 or something. I don't recommend
4096-character session ids ;)
Without SSL, though, remember that anyone who is capable of hijacking
the session is probably also capable of sniffing your users'
credentials. What are the implications of that? If it is unacceptable to
have your credentials go over the network in cleartext, then you will
simply have to break down and use SSL.
I'm glad to see that someone is actually thinking about security issues
instead of implementing something that sounds good. Nice job, John!
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFulsm9CaO5/Lv0PARAlhHAKCgXuG3hhiHfbsx6aVhgeay3zdjHACaA/aU
1JbkZa2E2HttdagKaFFOCqw=
=tmiH
-----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