yeah, I've found that, too, although getRemoteHost theoretically should return the machine name in many cases, but sometimes it won't.
-----Original Message----- From: Maurice Yarrow [mailto:[EMAIL PROTECTED] Sent: Saturday, August 12, 2006 2:45 AM To: Tomcat Users List Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it Hello Barry Generally, getRemoteHost() and getRemoteAddr() return the same value, but I had found a situation during testing where getRemoteAddr() returned an IP address but getRemoteHost() returned nothing. (That was two months ago, and I can't, at this time, remember the exact conditions under which this occurred.) Maurice Yarrow Propes, Barry L wrote: >what about getRemoteHost()? > >-----Original Message----- >From: Maurice Yarrow [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 10, 2006 5:30 PM >To: Tomcat Users List >Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it > > >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] > > >--------------------------------------------------------------------- >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] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
