I thought it was for some reason like that and I guess more environments are
closing that option off.
-Original Message-
From: David Rees [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 16, 2006 6:02 PM
To: Tomcat Users List
Subject: Re: Session hijacking with Tomcat/Myfaces - unable
On 8/16/06, Propes, Barry L <[EMAIL PROTECTED]> wrote:
From: Maurice Yarrow [mailto:[EMAIL PROTECTED]
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
o: 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 disc
tions 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 t
mmm, ok.
-Original Message-
From: David Rees [mailto:[EMAIL PROTECTED]
Sent: Friday, August 11, 2006 2:51 PM
To: Tomcat Users List
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
On 8/11/06, Propes, Barry L <[EMAIL PROTECTED]> wrote:
> what about getR
On 8/11/06, Propes, Barry L <[EMAIL PROTECTED]> wrote:
what about getRemoteHost()?
getRemoteHost is simply a getRemoteAddr with a reverse DNS lookup
thrown on top. No additional security there, in fact one could argue
that there is less.
-Dave
-
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
Maurice Yarrow wrote:
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 the
Tomas Hulek wrote:
Unfortunately, filters are skipped (ie. not called at all) when form-based
login page is processed as a result of client requesting a secure area.
We tried that too...
By the way, the original URL that the client requested is hidden in the
session in a way which prevents the
Supposing that your secure area is using a constantly
different URL path than your non-secure pages you
could create a filter to modify the default path for
the jsessionid cookie to be valid only for non-secure
pages.
For example, if your non-secure site is at
http://mysite.com/public/...
and you
ce-ip)?
Another question is can the original request IP be spoofed?
Long
- Original Message -
From: "Tomas Hulek" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Thursday, August 10, 2006 12:06 PM
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to
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 ambigu
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"
Sent: Thursday, August 10, 2006 2:53 PM
Subject: Re: Session hijacking with Tomcat/Myfaces
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 rela
quest IP be spoofed?
Long
- Original Message -
From: "Tomas Hulek" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
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 s
-
From: "Tomas Hulek" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
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
>
Unfortunately, filters are skipped (ie. not called at all) when form-based
login page is processed as a result of client requesting a secure area.
We tried that too...
By the way, the original URL that the client requested is hidden in the
session in a way which prevents the web app from copying
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 se
Well HTTP Cookies have a solution to this problem. They have a "Secure"
keyword in the Set-Cookie line. This stops the client leaking the
cookie outside of a secure channel.
The problem is I dont think Tomcat keeps track and flags if a session
has been exposed via a non-secure channel or
Right. Tomcat stores the original request info in the session before
redirecting to the login page. Invalidate the session and the original
request url is gone.
You could try (and I haven't tried this) is to find the original request
info stored in the old session, pull it out of the old ses
Tomas Hulek wrote:
> Any hints how to fix it?
Again, do all access to your app under https.
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Unfortunately, the fundamentally bad security scheme is how the JS API
specification is implemented in Tomcat (when using form-based
authentication).
When processing a form-based authetication request under HTTPS, Tomcat
retains the session ID allocated under HTTP.
We have tried invalidating the
It's a fundamentally bad security scheme to use the session-ID as the
identifier for your users. Might be straight forward, but architecturally a
bad choice if you *really* want a secure area.
Kim :-)
On 8/9/06, Tomas Hulek <[EMAIL PROTECTED]> wrote:
The default Tomcat installation is prone t
Tomas Hulek wrote:
> The default Tomcat installation is prone to session hijacking. I would
> appreciate help how to fix it.
This is a more general http problem with a well known solution. Do
everything over https.
Mark
-
To sta
24 matches
Mail list logo
