Long:
Thanks for adding this thought. As per my previous note on this
subject, in light of your (relative) confidence in using IP, maybe
I _should_ reconsider the getRemoteAddr() and simply use it as an
addt'l advisory for making session auth decision on successive
pages as they transit http/https.
Maurice Yarrow
Long wrote:
I can also imagine this company gives employees the go-a-head and
hijack each others session. It would also reward the idiot(s) that can
do it best with double pay...
Your imaginary company example doesn't really happen within a real
company, does it? Usually there are codes of conduct and policies
against such malice behavior, with serious consequences. I think
the risk is rather low than "relatively high", as you say.
Even if you can enforce a "SAFE" session, what is there to stop
a user from reconstructing his URL (with session ID and all) and
email it to friends and company?
Session hijacking is a potential problem with all web apps, regardless
of technology. The only thing we can do, falling short of making the user
authenticate with each request, is to determine the right balance between
content security and risk. For most applications, I would feel reasonably
secure if requests for a session are indeed coming from the same IP.
Long
----- Original Message -----
From: "Tomas Hulek" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Thursday, August 10, 2006 2:53 PM
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
In this case the chances are relatively high - imagine a company using a
proxy to connect to the Internet. The client IP does not change, a someone
in the company sniffing can easily hijack sessions from his/her colleagues.
Tomas
"Long"
<[EMAIL PROTECTED]
om> To
"Tomcat Users List"
10.08.2006 18:30 <users@tomcat.apache.org>
cc
Please respond to Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<[EMAIL PROTECTED]
che.org>
I wonder if associating (and checking) the request IP with the session
would reduce the problem to some acceptable level. What is
the chance of a session being hijacked from the same network (face-ip)?
Another question is can the original request IP be spoofed?
Long
----- Original Message -----
From: "Tomas Hulek" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Thursday, August 10, 2006 12:06 PM
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
We have tried it, but the internal session attributes where Tomcat stores
the original request are hidden to application, and are certainly not
accessible to javax.servlet.* API (and we do try to write PORTABLE
application, relying on the specification and not on the internals of one
particular servlet engine).
Commenting on other suggestions
1) SSL for the whole application is not practical, there are many users
who
only use the public pages and never log in.
2) We have implemented one workaround in the login-form
if the session was not generated under SSL do the following:
- invalidate session
- create new session and mark it as safe (generated under SSL)
- do an external redirect to a fixed, non-public page
The last step will start the whole login process again, this time with a
safe session ID.
I am still not happy with it. A very enhancement in Tomcat would do:
generate new session ID after switch to HTTPS, based eg. on the SSL
session
ID (to get a new, unique ID).
Tomas
---------------------------------------------------------------------
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]
