On 02/09/2010 01:47, Len Popp wrote:
> On Wed, Sep 1, 2010 at 19:08, Konstantin Kolinko
> wrote:
>> Have you ever searched the list archives?
>
> Good idea...
> http://tomcat.markmail.org/search/?q=hijack#query:hijack%20list%3Aorg.apache.tomcat.users+page:1+state:facets
> More than 700 messages!
On Wed, Sep 1, 2010 at 19:08, Konstantin Kolinko wrote:
> Have you ever searched the list archives?
Good idea...
http://tomcat.markmail.org/search/?q=hijack#query:hijack%20list%3Aorg.apache.tomcat.users+page:1+state:facets
More than 700 messages! Really, is there a reason they all need to be
sent
> Have you ever searched the list archives? Hijacked threads are
> harmful. I appreciate those complaints being on the list, so that I
> won't waste my time replying (and increasing the mess).
>
In that case the answer is yes. I should read this in a threaded client.
-
2010/9/2 Len Popp :
> On Wed, Sep 1, 2010 at 18:06, Christopher Schultz
> wrote:
>> In the end, it's mostly up to the user's own personal preference which
>> way things should go. Those of us whose mail clients respect the
>> thread-id in the SMTP headers can see immediately when someone hijacks a
--Original Message-
> From: Len Popp [mailto:len.p...@gmail.com]
> Sent: Wednesday, September 01, 2010 4:28 PM
> To: Tomcat Users List
> Subject: Re: META - Thread Hijacking
>
> On Wed, Sep 1, 2010 at 18:06, Christopher Schultz
> wrote:
> > In the end, it's mostl
On Wed, Sep 1, 2010 at 18:06, Christopher Schultz
wrote:
> In the end, it's mostly up to the user's own personal preference which
> way things should go. Those of us whose mail clients respect the
> thread-id in the SMTP headers can see immediately when someone hijacks a
> thread. Those folks have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wesley,
On 9/1/2010 5:39 PM, Wesley Acheson wrote:
> I've seen complaints about thread hijacking but I always see them as
> different threads in my mail client. (Gmail) should I be using
> different software to subscribe to the lis
> From: Wesley Acheson [mailto:wesley.ache...@gmail.com]
> Subject: META - Thread Hijacking
> I've seen complaints about thread hijacking but I always see
> them as different threads in my mail client.
Newer e-mail readers tend to ignore much of the SMTP header information and
I've seen complaints about thread hijacking but I always see them as
different threads in my mail client. (Gmail) should I be using
different software to subscribe to the list I think I've replied to
them (threadjacks) a few tim
Sorry, i'll remember this not just for you, but for everyone to specifically
use new for new threads.
--
From: "ULS Tech Support"
Sent: Tuesday, October 20, 2009 1:13 PM
To: "Tomcat Users List" ;
Subject: Re: Hijacking
Fair enough... I didn't think it was a big deal to do that... clicking new
instead of reply... But really, i am still asking a valid question and
require help...
Didn't realize that this thread hijacking was going to cause someone to tell
me what i did wrong, when i still h
On 20/10/2009 19:02, ULS Tech Support wrote:
Tell me how i hijacked my own thread?
As I described. See?
This is my own thread.. and i actually modified the last one i sent out,
cleared everything and typed out brand new.
Umm, yes, that would be what we call hijacking.
You hijacked a
://testweb/testpageaction.do;jsessionid=SD23SL4DE134ADFF565D
If I execute this same URL in another machine, then I am able to browse
my webapp, as if I was logged in. I expected the session to be invalid
for this request.
I've searched Google for jsessionid hijacking and found some ways to
a
> From: Zaki Akhmad [mailto:zakiakh...@gmail.com]
> 2009/3/13 zhaoxueqing :
>
> > jsessionid is the only way to indentity the user logined.
> > if you get it ,you are this user.
> > but? we can check others , for example IP!
Difficult, depending on your environment. Some ISPs run large proxy clus
Just a word about associating a given session to one IP address, it
works alright and sure is a security enhancement - not sure though if
there are built-in support for that in tomcat though it can be
implemented at application layer. The major drawback of doing so
depends of your user's ISP IPs ma
2009/3/13 zhaoxueqing :
> jsessionid is the only way to indentity the user logined.
> if you get it ,you are this user.
> but? we can check others , for example IP!
But we can *still* do IP spoofing. Any other better recomendation?
This issue is one of my concern also.
--
Zaki Akhmad
-
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> I don't know. It just seemed way to easy to hijack a session, so I
> supposed it must be secure.
Large portions of the web architecture are insecure by their original design.
This makes security in web-based systems... erm.. "a challen
> > However, as the jsessionid URL rewriting is defined in the servlet
> > specification, I would expect this to be secure.
>
> Why, out of interest?
I don't know. It just seemed way to easy to hijack a session, so I
supposed it must be secure.
> It's completely normal. Other frameworks have ex
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> However, as the jsessionid URL rewriting is defined in the servlet
> specification, I would expect this to be secure.
Why, out of interest?
> Therefor I was wondering whether the hijacking is caused by a
> misconfigur
jsessionid is the only way to indentity the user logined.
if you get it ,you are this user.
but? we can check others , for example IP!
- Original Message -
From: "Pieter Temmerman"
To: "Tomcat Users List"
Sent: Friday, March 13, 2009 5:15 PM
Subject: JSESSIO
eaction.do;jsessionid=SD23SL4DE134ADFF565D
If I execute this same URL in another machine, then I am able to browse
my webapp, as if I was logged in. I expected the session to be invalid
for this request.
I've searched Google for jsessionid hijacking and found some ways to
avoid jsessionid to appear in
> From: Jasbinder Singh Bali [mailto:[EMAIL PROTECTED]
> Isn't there any feature in tomcat itself that would
> automatically take care
> of session hijacking without doing something at web application level.
Not in all cases. SSL deals with untrusted networks, but if you can&#
Jasbinder Singh Bali wrote:
And how should i get rid of session hijacking. Is there any feature is
tomcat that takes care of it?
On 4/4/07, Mikolaj Rydzewski <[EMAIL PROTECTED]> wrote:
Jasbinder Singh Bali wrote:
>> In short, i need to demonstrate session hijacking in apache
> From: Mikolaj Rydzewski [mailto:[EMAIL PROTECTED]
> Jasbinder Singh Bali wrote:
> > And how should i get rid of session hijacking. Is there any
> feature is
> > tomcat that takes care of it?
> Figure it out yourself, it's not so hard ;-)
>
> I.e. you can sto
Isn't there any feature in tomcat itself that would automatically take care
of session hijacking without doing something at web application level.
something like the way BadInputFilering valve in Tomcat tries to escape
certain string patterns from the GET and POST parameter names and valu
: Mikolaj Rydzewski [mailto:[EMAIL PROTECTED]
Sent: 04 April 2007 16:04
To: Tomcat Users List
Subject: Re: Session Hijacking with Apache Tomcat
Jasbinder Singh Bali wrote:
> And how should i get rid of session hijacking. Is there any feature is
> tomcat that takes care of it?
Figure it out yo
Jasbinder Singh Bali wrote:
And how should i get rid of session hijacking. Is there any feature is
tomcat that takes care of it?
Figure it out yourself, it's not so hard ;-)
I.e. you can store client's IP address in a session, and compare it with
every request. If they don
> From: Jasbinder Singh Bali [mailto:[EMAIL PROTECTED]
> And how should i get rid of session hijacking. Is there any feature is
> tomcat that takes care of it?
I shouldn't do your work for you, but... just hope your supervisor
doesn't read tomcat-users :-).
Demonstrate: the s
And how should i get rid of session hijacking. Is there any feature is
tomcat that takes care of it?
On 4/4/07, Mikolaj Rydzewski <[EMAIL PROTECTED]> wrote:
Jasbinder Singh Bali wrote:
>> In short, i need to demonstrate session hijacking in apache tomcat and
>> then show meas
Jasbinder Singh Bali wrote:
Hi,
I have to demonstrate Session Hijacking with Apache Tomcat to my advisor
when some precautionary measures are not taken.
Maybe securityfocus.com has some information on that?
-
To start a new
Jasbinder Singh Bali wrote:
In short, i need to demonstrate session hijacking in apache tomcat and
then show measures that would be
taken to get rid of it.
Any kind of help would be highly appreciated.
Turn off cookies, Tomcat should then rewrite URLs to include jsessionid.
Then it's tr
Hi,
I have to demonstrate Session Hijacking with Apache Tomcat to my advisor
when some precautionary measures are not taken.
I'm just wondering how can I do this.
After a satisfactory demonstration, I need to demonstrate the steps I
would take to get rid of this session hijacking.
In sho
-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
> 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
,
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
check
-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
e le reproduire.
- Original Message -
From: "John Caron" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
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 inst
riginal Message -
From: "John Caron" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Monday, January 29, 2007 3:17 PM
Subject: Re: session hijacking again
> Hi Peter:
>
> Peter Stavrinides wrote:
>> Do you use Java?
>
> yes
>
>&g
ession 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
>&
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 s
, 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.
Just make sure that your users don't use the same username and password
they use for their online banking. Seri
ld 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 r
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 financi
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
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
e: 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
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
e this sort of thing before with success and the
filter is pretty lightweight, so there is little
performance impact.
-marc
--- Tomas Hulek <[EMAIL PROTECTED]> wrote:
> The default Tomcat installation is prone to session
> hijacking. I would
> appreciate help how to fix it.
>
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
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
nds 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
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
Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<[EMAIL PROTECTED]
-
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
>
Subject
"Tomcat Users Re: Session hijacking with
List" Tomcat/Myfaces - unable to fix it
<[EMAIL PROTECTED]
13:16
cc
Please respond to Subject
"Tomcat Users Re: Session hijacking with
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
-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 to session hijacking. I would
appreciate he
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:
gt; Kim :-)
>
> On 8/9/06, Tomas Hulek <[EMAIL PROTECTED]> wrote:
> >
> > The default Tomcat installation is prone to session hijacking. I would
> > appreciate help how to fix it.
> >
> > The problem is that the session-id generated under HTTP (eg. for any
JSF
&g
on is prone to session hijacking. I would
appreciate help how to fix it.
The problem is that the session-id generated under HTTP (eg. for any JSF
page) is caried over to authenticated confidential pages under HTTPS.
Thus the session ID can be easily sniffed under HTTP, then misused after
user lo
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
--
The default Tomcat installation is prone to session hijacking. I would
appreciate help how to fix it.
The problem is that the session-id generated under HTTP (eg. for any JSF
page) is caried over to authenticated confidential pages under HTTPS.
Thus the session ID can be easily sniffed under
Thanks, Charles and Bill. This has been most helpful. I will be
looking and both alternatives.
mike
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Bill Barker
Sent: Saturday, October 15, 2005 5:56 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: Hijacking the
There should never be a reason to replace the Connector in Tomcat, since all
it does is serve as a bridge. Also, in TC 5.5.x, the Connector is strongly
integrated with the container code, so it is is almost certainly more
trouble than it is worth to try.
The recommended way to do what it sound
71 matches
Mail list logo
