Hello David, Tomas:
About two months ago, I tried using the getRemoteAddr() for doing IP
check as an addtional auth metric, but found exactly than on local
net, this did not discriminate in many cases and only a single IP
was returned for hosts on LAN. So I decided that there was too
much ambiguity to use this approach, even as addt'l metric.
One could however assume validity of positives but ignore false
negatives, i.e., if IP in conflict with orig, assume man-in-middle
attack, but if IP agrees, must rely on other metrics to determine
possible jeopardy.
Maurice Yarrow
David Rees wrote:
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?
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.
Checking the request IP to ensure that it matches the session is a
good idea, though it doesn't stop all attacks.
If you were to do that, you could also easily add a session attribute
indicating whether the session was created under http or https and
invalidate/create a new session if a http session is attempted to be
used under https.
Besides that, as others suggested, the best thing to do is to simply
put everything under SSL.
-Dave
---------------------------------------------------------------------
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]
