You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Scott Hamilton <sc...@plateau.com> on 2010/08/18 00:01:38 UTC
Is there a better way to disable JSESSIONID in the URLs?
Using Tomcat 6.0.29, but I think this is version-independent (correct me
if I'm wrong), at least for the 6.0.x versions.
>From what I understand (see
http://randomcoder.com/articles/jsessionid-considered-harmful for
instance - I also scanned various aspects of the tomcat source code)
there is no way to disable tomcat from putting the JSESSIONID in URLs
automatically with a nice friendly global switch/property. The only way
I've seen how to do this, as suggested on the site I referenced, is to
put into place a servlet filter.
I'd like to know if I'm missing anything - is there a better way to do
this?
We have an app whose security is a concern for our customers, and
JSESSIONIDs appearing in the URLs freak them out (especially when they
demonstrate that you can get a URL from the app, email it to someone
else, and have that person magically bypass authentication and assume
the role of the other user - of course as long as the session is still
valid).
We are comfortable saying that in order to use our application you need
to have cookies enabled, so I'm making the assumption that if we disable
the feature of putting JSESSIONID into the URLs, either through a nice
global switch or else a servlet filter, cookie-based session
setting/tracking will still function just as we expect it.
Finally, anyone know why this isn't already in the servlet spec? Seems
like with more and more concern over web application security that this
would be something the spec should address?
Thanks,
Scott
.
The information contained in this e-mail message is intended only for the personal
and confidential use of the recipient(s) named above. This message is privileged
and confidential. If the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are hereby notified
that you have received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited.
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
Wow. I wrote a book. Sorry for my uncharacteristically long exposition.
On 8/18/2010 5:40 AM, André Warnier wrote:
> Could/should not Tomcat at least verify, when it gets a JSESSIONID from
> a client and retrieves the corresponding session information, that the
> IP address of this current client matches the client IP address (which
> would have been) previously stored in the session ?
>
> Or would this introduce other problems ?
Sometimes a user's IP changes for one of several reasons:
1. Internet connection dies / re-establishes with a new BOOTP/DHCP IP
2. Came through a different proxy on different requests
3. You have AOL, who apparently loves to play games with IPs
This is a good security feature to allow users to opt-into, though.
There's a filter in securityfilter (have I committed it, yet?) to do
just this, and it's user-selectable at login (or any time? I'll have to
look at the code again).
> I know that it is not really a "solution", because hapless users will
> anyway continue (mostly innocently) to email links to their colleagues,
> and they will wonder why they do not work.
If security has been implemented correctly, Tomcat will ask the user for
their credentials and ultimately give access to the requested resource
once authentication has been completed successfully. That's part of the
spec: one that works quite well for users IMO.
> If I understand correctly how it works, then currently the following
> scenario is possible, isn't it ?
>
> But because the link contains the jsessionid of the first user, the
> colleague would gain access to the resource, without either one of them
> even thinking about it.
Yup. This is called session hijacking. It can be performed against any
web server using non-SSL sessions (I mean an SSL-session, not just an
HTTP session being used over HTTPS).
Note that "disabling" the jsessionid parameter being added to URLs does
not in the slightest way prevent a hacker from crafting a URL that
contains a jsessionid and using it to hijack a session.
Not only that, but there's no spec or Tomcat requirement that the
session be accessed via SSL. That means that if you, André (the "good
guy") log into your secure web application using HTTPS and establish a
session, I (the "bad guy") can hit
http://yourserver/secretStuff.jsp?jsessionid=12345 and, if I've guessed
your session id correctly, I get to masquerade as you. In fact, I
believe Tomcat will continue sending Set-Cookie headers, so once I've
sent my specially-crafted URL to the server, I don't even have to go
through the pain of re-writing every URL I see: I've got the same cookie
you do, now, too (except mine probably doesn't have secure=true set).
Note that guessing a session id is non-trivial, so it may take a long
time to accomplish. The good news for hackers is that there is no
built-in anti-hacking mechanism to prohibit remote users from simply
attempting to hijack session id after session id, so they can try all
day to break into a standard Tomcat server.
No, I haven't yet written a filter that can capture these attacks and
try to mitigate them.
> This is inside a corporate LAN, where one would normally tend to
> consider communications as "trusted", and thus to not really need SSL.
Hah. Trust no one.
> But by simply exchanging this link, the users unwittingly or not break
> the access control mechanisms buried deep into an application.
> Furthermore, now these two users can continue to interact with the
> application, both within the same Tomcat session, although they are on
> different workstations altogether ?
>
> To me, that sounds really bad.
It's not terribly good. Note that the presence of the jsessionid in the
URL is not really the attack vector: it just makes the attack vector
slightly more convenient for hackers or idiots. Cookies have the same
"danger" in that anyone can send any cookie to any web server. The real
problem is allowing remote clients to self-authenticate -- that is,
provide an otherwise non-corroborated credential (that's the session id)
to the server. The only really good way to secure a session to a single
user is to use SSL client certificates with the cert fingerprint stored
in the session. Even then, the client cert can be shared with others so
you're really just shrinking the pool of potential session hijackers to
those who might be able to get their hands on an SSL cert.
With credentials, it's always something you know or something you have
(or something you /are/, but that's not practical for web-based
security). Something you know can always be guessed if given enough
time. Something you have is almost always better than something you
know, especially if it's not duplicatable (is that a word?) like one of
those dongles they used to use for software licenses. Coupling the two
is pretty much as good as you can get (which is why they call it
"two-factor authentication" and why it gets so much hype).
By the way, anyone not using SSL certificates who says they use
two-factor authentication for web-based security is lying to you: they
are using dual-single-factor authentication which isn't the same thing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxsrlMACgkQ9CaO5/Lv0PBOwwCglfn3vlTddtQ1Sgo74QavDdcP
oMgAoL/D+NzPfpJDYEo4DWCj6/EeLBXh
=3En+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: Scott Hamilton [mailto:scott.hamilton@plateau.com]
>> Subject: RE: Is there a better way to disable JSESSIONID in the URLs?
>>
>> I could be missing something, but on a request where a session is
>> created it appears as though Tomcat will both set the cookie AND
>> do any necessary URL rewriting in order to ensure that the cookie
>> is preserved.
>
> Sorry, you're right; at that point Tomcat doesn't know if the client supports cookies. However, when skimming through the Tomcat code, the only internal call to encodeURL() that I can find appears to be called only for relative URLs, so possibly making your initial URLs absolute might avoid appending the jsessionid. (But I could have easily missed a call, and there may be another method that's doing the appending.)
>
>> The issue in question isn't so much about determined hackers
>> but hapless users who will bookmark URLs or worse, copy URLs
>> to email to their co-workers.
>
> "Hapless" being the operative word. I think you're stuck with using a filter.
>
Could/should not Tomcat at least verify, when it gets a JSESSIONID from a client and
retrieves the corresponding session information, that the IP address of this current
client matches the client IP address (which would have been) previously stored in the
session ?
Or would this introduce other problems ?
I know that it is not really a "solution", because hapless users will anyway continue
(mostly innocently) to email links to their colleagues, and they will wonder why they do
not work.
And it is not a foolproof security system either.
But at least then these links would not so easily "work" and give cold sweats to these
people's network admins.
If I understand correctly how it works, then currently the following scenario is possible,
isn't it ?
Within a corporate LAN, all users must login into their workstation using some form of
network login (in 99% of the practical cases, that would be Windows NTLM).
Then they call up an application residing on a corporate Tomcat host. This host is
configured so as to automatically pick up the user's network user-id (through e.g. Jespa,
or Waffle, or similar), and use it as the "Tomcat user-id".
Then this first user session gets a tomcat session and associated JSESSIONID.
The application checks that the user session is authenticated, but also controls access to
some information in function of this user-id.
Now this particular user gets a link to a resource, accessible to his user-id, and then
copies that link to a colleague (also logged-in into the corporate network), who normally
would not have access to that resource.
But because the link contains the jsessionid of the first user, the colleague would gain
access to the resource, without either one of them even thinking about it.
This is inside a corporate LAN, where one would normally tend to consider communications
as "trusted", and thus to not really need SSL.
The authentication method is fairly secure, in the sense that passwords are not exchanged,
and Tomcat can "trust" the user-id as received by the first user's authentication method.
But by simply exchanging this link, the users unwittingly or not break the access control
mechanisms buried deep into an application.
Furthermore, now these two users can continue to interact with the application, both
within the same Tomcat session, although they are on different workstations altogether ?
To me, that sounds really bad.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Scott Hamilton [mailto:scott.hamilton@plateau.com]
> Subject: RE: Is there a better way to disable JSESSIONID in the URLs?
>
> I could be missing something, but on a request where a session is
> created it appears as though Tomcat will both set the cookie AND
> do any necessary URL rewriting in order to ensure that the cookie
> is preserved.
Sorry, you're right; at that point Tomcat doesn't know if the client supports cookies. However, when skimming through the Tomcat code, the only internal call to encodeURL() that I can find appears to be called only for relative URLs, so possibly making your initial URLs absolute might avoid appending the jsessionid. (But I could have easily missed a call, and there may be another method that's doing the appending.)
> The issue in question isn't so much about determined hackers
> but hapless users who will bookmark URLs or worse, copy URLs
> to email to their co-workers.
"Hapless" being the operative word. I think you're stuck with using a filter.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Posted by Scott Hamilton <sc...@plateau.com>.
Thanks for the reply.
> Tomcat won't put the jsessionid in the URL unless cookies are
disabled. If they are, then your webapp could refuse to talk to the
client.
I could be missing something, but on a request where a session is
created it appears as though Tomcat will both set the cookie AND do any
necessary URL rewriting in order to ensure that the cookie is preserved.
If the session (a) already exists and (b) was received in the request
through a cookie reference it will NOT do the URL rewriting. I'm
assuming this is to cover the bases and ensure a JSESSIONID gets
injected into the following requests regardless of the client's cookie
acceptance policy.
>>
And the id value in a cookie doesn't? What stops anyone from e-mailing
the cookie to someone else?
If someone is truly concerned about security, then they *must* run *all*
traffic through SSL. If the customers don't do that, they're not really
concerned, despite whatever words they're using.
<<
You're absolutely correct, and SSL is used for our security-conscious
customers. The issue in question isn't so much about determined hackers
but hapless users who will bookmark URLs or worse, copy URLs to email to
their co-workers.
-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
Sent: Tuesday, August 17, 2010 6:16 PM
To: Tomcat Users List
Subject: RE: Is there a better way to disable JSESSIONID in the URLs?
> From: Scott Hamilton [mailto:scott.hamilton@plateau.com]
> Subject: Is there a better way to disable JSESSIONID in the URLs?
>
> there is no way to disable tomcat from putting the JSESSIONID in URLs
> automatically with a nice friendly global switch/property.
Tomcat won't put the jsessionid in the URL unless cookies are disabled.
If they are, then your webapp could refuse to talk to the client.
> We have an app whose security is a concern for our customers, and
> JSESSIONIDs appearing in the URLs freak them out
And the id value in a cookie doesn't? What stops anyone from e-mailing
the cookie to someone else?
If someone is truly concerned about security, then they *must* run *all*
traffic through SSL. If the customers don't do that, they're not really
concerned, despite whatever words they're using.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
.
The information contained in this e-mail message is intended only for the personal
and confidential use of the recipient(s) named above. This message is privileged
and confidential. If the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are hereby notified
that you have received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Len Popp <le...@gmail.com>.
On 2010-08-17, at 18:15, "Caldarale, Charles R" <Chuck.Caldarale@unisys.com
> wrote:
> Tomcat won't put the jsessionid in the URL unless cookies are
> disabled. If they are, then your webapp could refuse to talk to the
> client.
That's not true. Tomcat doesn't know if cookies are available until
the second request, so the first page you get is full of URLs with
jsessionids.
Also search engine bots don't seem to use cookies. I saw lots of
pointless re-re-re-crawling by search bots until I cleaned up the URLs.
--
Len
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Scott Hamilton [mailto:scott.hamilton@plateau.com]
> Subject: Is there a better way to disable JSESSIONID in the URLs?
>
> there is no way to disable tomcat from putting the JSESSIONID in URLs
> automatically with a nice friendly global switch/property.
Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client.
> We have an app whose security is a concern for our customers, and
> JSESSIONIDs appearing in the URLs freak them out
And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else?
If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Pid <pi...@pidster.com>.
On 19/08/2010 13:32, Scott Hamilton wrote:
> Sorry to pull the thread back to my original problem, but I have one
> more question here.
>
> So far it looks like there's no way to prevent JSESSIONIDs from being
> injected into URLs that Tomcat might encode unless you implement a
> servlet filter to override that behavior.
>
> My follow-up question is this: given the increasing emphasis on security
> (and acknowledging that there's as much fear-mongering as there is
> legitimate threats involved in that business and both cost money and
> time regardless of the legitimacy of the issue), does it make sense to
> for Tomcat, and maybe even the servlet spec, to provide the option for
> the servlet container to disable this functionality at the container
> level, e.g. with a container configuration switch somewhere?
You could always submit a patch and see what the devs think. ;)
p
> The information contained in this e-mail message is intended only for the personal
> and confidential use of the recipient(s) named above. This message is privileged
> and confidential. If the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you are hereby notified
> that you have received this document in error and that any review, dissemination,
> distribution, or copying of this message is strictly prohibited.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: Is there a better way to disable JSESSIONID in the URLs?
Posted by Scott Hamilton <sc...@plateau.com>.
Sorry to pull the thread back to my original problem, but I have one
more question here.
So far it looks like there's no way to prevent JSESSIONIDs from being
injected into URLs that Tomcat might encode unless you implement a
servlet filter to override that behavior.
My follow-up question is this: given the increasing emphasis on security
(and acknowledging that there's as much fear-mongering as there is
legitimate threats involved in that business and both cost money and
time regardless of the legitimacy of the issue), does it make sense to
for Tomcat, and maybe even the servlet spec, to provide the option for
the servlet container to disable this functionality at the container
level, e.g. with a container configuration switch somewhere?
.
The information contained in this e-mail message is intended only for the personal
and confidential use of the recipient(s) named above. This message is privileged
and confidential. If the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are hereby notified
that you have received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2010 14:33, Pid wrote:
> On 19/08/2010 20:41, Wesley Acheson wrote:
>> Is there anywhere we could vote for such a feature? I know Resin has it as
>> I've stated before.
>
> You could file an enhancement request in Bugzilla, but it would be more
> likely to get attention if it came with a patch. I can't comment as to
> whether it would be approved or not.
That depends on the patch ;) Personally, I like the idea.
Things I'd look for in a patch:
- is it configurable per context
- how invasive is it
I'd add that this is part of Servlet 3.0 and is supported in Tomcat 7.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Rainer Jung <ra...@kippdata.de>.
On 26.08.2010 23:29, Wesley Acheson wrote:
> On Sat, Aug 21, 2010 at 12:12 PM, Pid<pi...@pidster.com> wrote:
>> On 20/08/2010 22:40, Wesley Acheson wrote:
>>> I'm a bit lost with this thread. Are people suggesting I should submit a
>>> patch. I really wouldn't know where to begin looking.
>>
>> That's where the discussion was heading.
>>
>> Tomcat is Open Source. The first place to look would be SVN.
>>
>> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
>>
>>
>> p
>
> Hi everyone,
>
> I've done this and was naturally quite nervous about it having never
> contributed to anything in this way.
That's quite normal :)
It gets better once you do it more regularly ;)
> Would It be too much to ask to
> get some feedback if you have time? I'd really appreciate it.
> Feedback about anything from the code changes to if you feel the
> bugzilla report was adaquate.
It was a good initiative and I'm sure we will have a look at the patch.
Please be patient though. If you don't see any progress (comments in the
Bugzilla issue), then it is fine to nag after about one or two weeks.
> I do honestly appreciate that you are all busy but It could go a long
> way to encouraging new users to help chip in if they felt there was
> adaquate feedback. Much better to be honest though than to pamper to
> them. If anythings wrong with what I did I'd love to know but If it
> was okay I'd like to know also.
If it gets committed to the Tomcat source, you will see, whether there
was a need to change anything. All changes applied to the code are public.
> If this is a subject for the dev mail list then I'd appreciate being
> told that too. I didn't want to interrupt the dev mail list as it
> seems pretty busy with svn commits and bugzilla reports.
It is in the middle of the two lists, since most of the discussion was
here (users) I understand you reply here. If there is need to discuss
technical details of the patch, the discussion will switch over to
Bugzilla, or if the discussion switches topic, like starting to discuss
a more general implementation thing it might switch to the dev list.
> In case your not in a threaded email client the link was
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 again.
Thanks for starting to contribute!
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
On Sat, Aug 21, 2010 at 12:12 PM, Pid <pi...@pidster.com> wrote:
> On 20/08/2010 22:40, Wesley Acheson wrote:
>> I'm a bit lost with this thread. Are people suggesting I should submit a
>> patch. I really wouldn't know where to begin looking.
>
> That's where the discussion was heading.
>
> Tomcat is Open Source. The first place to look would be SVN.
>
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
>
>
> p
Hi everyone,
I've done this and was naturally quite nervous about it having never
contributed to anything in this way. Would It be too much to ask to
get some feedback if you have time? I'd really appreciate it.
Feedback about anything from the code changes to if you feel the
bugzilla report was adaquate.
I do honestly appreciate that you are all busy but It could go a long
way to encouraging new users to help chip in if they felt there was
adaquate feedback. Much better to be honest though than to pamper to
them. If anythings wrong with what I did I'd love to know but If it
was okay I'd like to know also.
If this is a subject for the dev mail list then I'd appreciate being
told that too. I didn't want to interrupt the dev mail list as it
seems pretty busy with svn commits and bugzilla reports.
In case your not in a threaded email client the link was
https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 again.
Regards,
Wesley Acheson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
Yeah don't get too hopeful. I'm not that familiar with the tomcat
code, however I think it works.
On Mon, Aug 23, 2010 at 8:59 PM, Scott Hamilton
<sc...@plateau.com> wrote:
> Awesome dude (that you submitted the patch so quick - I've not looked at
> it in detail yet). Thanks!
>
> -----Original Message-----
> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
> Sent: Monday, August 23, 2010 2:33 PM
> To: Tomcat Users List
> Subject: Re: Is there a better way to disable JSESSIONID in the URLs?
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49811
>
> On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas <ma...@apache.org> wrote:
>> On 22/08/2010 16:29, Wesley Acheson wrote:
>>> Sorry for bring this off list. I'll put it back on list if you think
> that
>>> appropriate.
>>>
>>> You think that the context is the correct place to put this? I
> thought maybe
>>> web.xml but I don't know if you can extend that or if its rigidly
> covered by
>>> the spec.
>>
>> web.xml is defined by the spec. You can't touch it.
>>
>>> I started to do this on the connector is that incorrect?
>>
>> The configuration needs to be per context. Look at the
> sessionCookieName
>> attribute as an example.
>>
>> For the place to actually diable it, look in the
>> o.a.c.connector.Response.isEncodeable() method. If you look in the TC7
>> code, you'll see how the Servlet 3.0 stuff was implemented.
>>
>>> How would one submit a patch? Sorry I've never done this for any
> project. Do
>>> I just attach the changed source files to bugzilla? or do I need to
> do a
>>> diff and create a patch file.
>>
>> Patch please, in diff -u format. Bugzilla is the right place.
>>
>>> I'm on windows so I've never used patch and I
>>> am unsure how to create one. (unix patch file)
>>
>> I use TortoiseSVN and Eclipse on Windows. Both these tools generate
>> suitable patch files.
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> .
> The information contained in this e-mail message is intended only for the personal
> and confidential use of the recipient(s) named above. This message is privileged
> and confidential. If the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you are hereby notified
> that you have received this document in error and that any review, dissemination,
> distribution, or copying of this message is strictly prohibited.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Posted by Scott Hamilton <sc...@plateau.com>.
Awesome dude (that you submitted the patch so quick - I've not looked at
it in detail yet). Thanks!
-----Original Message-----
From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
Sent: Monday, August 23, 2010 2:33 PM
To: Tomcat Users List
Subject: Re: Is there a better way to disable JSESSIONID in the URLs?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49811
On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas <ma...@apache.org> wrote:
> On 22/08/2010 16:29, Wesley Acheson wrote:
>> Sorry for bring this off list. I'll put it back on list if you think
that
>> appropriate.
>>
>> You think that the context is the correct place to put this? I
thought maybe
>> web.xml but I don't know if you can extend that or if its rigidly
covered by
>> the spec.
>
> web.xml is defined by the spec. You can't touch it.
>
>> I started to do this on the connector is that incorrect?
>
> The configuration needs to be per context. Look at the
sessionCookieName
> attribute as an example.
>
> For the place to actually diable it, look in the
> o.a.c.connector.Response.isEncodeable() method. If you look in the TC7
> code, you'll see how the Servlet 3.0 stuff was implemented.
>
>> How would one submit a patch? Sorry I've never done this for any
project. Do
>> I just attach the changed source files to bugzilla? or do I need to
do a
>> diff and create a patch file.
>
> Patch please, in diff -u format. Bugzilla is the right place.
>
>> I'm on windows so I've never used patch and I
>> am unsure how to create one. (unix patch file)
>
> I use TortoiseSVN and Eclipse on Windows. Both these tools generate
> suitable patch files.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
.
The information contained in this e-mail message is intended only for the personal
and confidential use of the recipient(s) named above. This message is privileged
and confidential. If the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are hereby notified
that you have received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49811
On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas <ma...@apache.org> wrote:
> On 22/08/2010 16:29, Wesley Acheson wrote:
>> Sorry for bring this off list. I'll put it back on list if you think that
>> appropriate.
>>
>> You think that the context is the correct place to put this? I thought maybe
>> web.xml but I don't know if you can extend that or if its rigidly covered by
>> the spec.
>
> web.xml is defined by the spec. You can't touch it.
>
>> I started to do this on the connector is that incorrect?
>
> The configuration needs to be per context. Look at the sessionCookieName
> attribute as an example.
>
> For the place to actually diable it, look in the
> o.a.c.connector.Response.isEncodeable() method. If you look in the TC7
> code, you'll see how the Servlet 3.0 stuff was implemented.
>
>> How would one submit a patch? Sorry I've never done this for any project. Do
>> I just attach the changed source files to bugzilla? or do I need to do a
>> diff and create a patch file.
>
> Patch please, in diff -u format. Bugzilla is the right place.
>
>> I'm on windows so I've never used patch and I
>> am unsure how to create one. (unix patch file)
>
> I use TortoiseSVN and Eclipse on Windows. Both these tools generate
> suitable patch files.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
> Subject: Re: Is there a better way to disable JSESSIONID in the URLs?
>
> I wan't actually going to do it but I think the specs should
> allow vendor extensions to web.xml.
That would be a really bad idea, and pretty much kill off any chance of portability. Separate container-specific structures (such as what Tomcat uses) are much less intrusive. We don't want to recreate the SQL dialect mayhem...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas <ma...@apache.org> wrote:
> On 22/08/2010 16:29, Wesley Acheson wrote:
> > Sorry for bring this off list. I'll put it back on list if you think that
> > appropriate.
> >
> > You think that the context is the correct place to put this? I thought
> maybe
> > web.xml but I don't know if you can extend that or if its rigidly covered
> by
> > the spec.
>
> web.xml is defined by the spec. You can't touch it.
>
Okay I thought this is where I saw it in Resin 2. I wan't actually going to
do it but I think the specs should allow vendor extensions to web.xml.
>
> > I started to do this on the connector is that incorrect?
>
> The configuration needs to be per context. Look at the sessionCookieName
> attribute as an example.
>
> For the place to actually diable it, look in the
> o.a.c.connector.Response.isEncodeable() method. If you look in the TC7
> code, you'll see how the Servlet 3.0 stuff was implemented.
>
Great this is where I put my initial code.
>
> > How would one submit a patch? Sorry I've never done this for any project.
> Do
> > I just attach the changed source files to bugzilla? or do I need to do a
> > diff and create a patch file.
>
> Patch please, in diff -u format. Bugzilla is the right place.
>
> > I'm on windows so I've never used patch and I
> > am unsure how to create one. (unix patch file)
>
> I use TortoiseSVN and Eclipse on Windows. Both these tools generate
> suitable patch files.
>
Thanks.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Mark Thomas <ma...@apache.org>.
On 22/08/2010 16:29, Wesley Acheson wrote:
> Sorry for bring this off list. I'll put it back on list if you think that
> appropriate.
>
> You think that the context is the correct place to put this? I thought maybe
> web.xml but I don't know if you can extend that or if its rigidly covered by
> the spec.
web.xml is defined by the spec. You can't touch it.
> I started to do this on the connector is that incorrect?
The configuration needs to be per context. Look at the sessionCookieName
attribute as an example.
For the place to actually diable it, look in the
o.a.c.connector.Response.isEncodeable() method. If you look in the TC7
code, you'll see how the Servlet 3.0 stuff was implemented.
> How would one submit a patch? Sorry I've never done this for any project. Do
> I just attach the changed source files to bugzilla? or do I need to do a
> diff and create a patch file.
Patch please, in diff -u format. Bugzilla is the right place.
> I'm on windows so I've never used patch and I
> am unsure how to create one. (unix patch file)
I use TortoiseSVN and Eclipse on Windows. Both these tools generate
suitable patch files.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
Sorry for bring this off list. I'll put it back on list if you think that
appropriate.
You think that the context is the correct place to put this? I thought maybe
web.xml but I don't know if you can extend that or if its rigidly covered by
the spec.
I started to do this on the connector is that incorrect?
How would one submit a patch? Sorry I've never done this for any project. Do
I just attach the changed source files to bugzilla? or do I need to do a
diff and create a patch file. I'm on windows so I've never used patch and I
am unsure how to create one. (unix patch file)
Regards,
Wesley Acheson
On Sat, Aug 21, 2010 at 12:12 PM, Pid <pi...@pidster.com> wrote:
> On 20/08/2010 22:40, Wesley Acheson wrote:
> > I'm a bit lost with this thread. Are people suggesting I should submit a
> > patch. I really wouldn't know where to begin looking.
>
> That's where the discussion was heading.
>
> Tomcat is Open Source. The first place to look would be SVN.
>
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
>
>
> p
>
> > On Fri, Aug 20, 2010 at 7:47 PM, Pid <pi...@pidster.com> wrote:
> >
> >> On 20/08/2010 17:35, Christopher Schultz wrote:
> >>> Pid,
> >>>
> >>> On 8/20/2010 8:33 AM, Pid wrote:
> >>>> On 19/08/2010 20:41, Wesley Acheson wrote:
> >>>>> On Thu, Aug 19, 2010 at 6:25 PM, Len Popp <le...@gmail.com>
> wrote:
> >>>>>
> >>>>>> On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
> >>>>>> <ch...@christopherschultz.net> wrote:
> >>>>>>> The servlet specification mandates this behavior. Tomcat simply
> must
> >>>>>>> support it. The spec says nothing of configurability, so Tomcat
> does
> >> not
> >>>>>>> provide any. Hence the need to write a filter to achieve your
> desired
> >>>>>>> behavior.
> >>>>>>
> >>>>>> That's not inviolable dogma. Tomcat does have some settings that
> make
> >>>>>> it operate out-of-spec, e.g. non-standard cookie parsing. I don't
> see
> >>>>>> why an option couldn't be added to disable JSESSIONID in URLs, if
> >>>>>> enough people would find it useful.
> >>>>>> --
> >>>>>> Len
> >>>>>
> >>>>>
> >>>>> Is there anywhere we could vote for such a feature? I know Resin has
> >> it as
> >>>>> I've stated before.
> >>>
> >>>> You could file an enhancement request in Bugzilla, but it would be
> more
> >>>> likely to get attention if it came with a patch. I can't comment as
> to
> >>>> whether it would be approved or not.
> >>>
> >>> This sounds like something that could easily be implemented as a Valve.
> >>> My understanding is that the only place where the jsessionid can't be
> >>> removed from URLs by a Filter is during the authentication process. A
> >>> Valve can be inserted /before/ the authentication/authorization
> Valve(s)
> >>> and therefore override the encodeURL behavior to perform /no/ URL
> >> rewriting.
> >>>
> >>> Maybe one of the TC devs can tell us how to insert a Valve /before/ the
> >>> AAA valves that are automatically set up by the security configuration
> >>> in web.xml, but never explicitly defined using a <Valve> element
> >> anywhere.
> >>
> >> Maybe look to see how it's implemented in v7.0 and hack something up.
> >>
> >> Taking Mark's hint and setting something on the Context, with effect on
> >> StandardContextValve maybe...
> >>
> >>
> >> p
> >>
> >>> -chris
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >>
> >
>
>
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Pid <pi...@pidster.com>.
On 20/08/2010 22:40, Wesley Acheson wrote:
> I'm a bit lost with this thread. Are people suggesting I should submit a
> patch. I really wouldn't know where to begin looking.
That's where the discussion was heading.
Tomcat is Open Source. The first place to look would be SVN.
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
p
> On Fri, Aug 20, 2010 at 7:47 PM, Pid <pi...@pidster.com> wrote:
>
>> On 20/08/2010 17:35, Christopher Schultz wrote:
>>> Pid,
>>>
>>> On 8/20/2010 8:33 AM, Pid wrote:
>>>> On 19/08/2010 20:41, Wesley Acheson wrote:
>>>>> On Thu, Aug 19, 2010 at 6:25 PM, Len Popp <le...@gmail.com> wrote:
>>>>>
>>>>>> On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
>>>>>> <ch...@christopherschultz.net> wrote:
>>>>>>> The servlet specification mandates this behavior. Tomcat simply must
>>>>>>> support it. The spec says nothing of configurability, so Tomcat does
>> not
>>>>>>> provide any. Hence the need to write a filter to achieve your desired
>>>>>>> behavior.
>>>>>>
>>>>>> That's not inviolable dogma. Tomcat does have some settings that make
>>>>>> it operate out-of-spec, e.g. non-standard cookie parsing. I don't see
>>>>>> why an option couldn't be added to disable JSESSIONID in URLs, if
>>>>>> enough people would find it useful.
>>>>>> --
>>>>>> Len
>>>>>
>>>>>
>>>>> Is there anywhere we could vote for such a feature? I know Resin has
>> it as
>>>>> I've stated before.
>>>
>>>> You could file an enhancement request in Bugzilla, but it would be more
>>>> likely to get attention if it came with a patch. I can't comment as to
>>>> whether it would be approved or not.
>>>
>>> This sounds like something that could easily be implemented as a Valve.
>>> My understanding is that the only place where the jsessionid can't be
>>> removed from URLs by a Filter is during the authentication process. A
>>> Valve can be inserted /before/ the authentication/authorization Valve(s)
>>> and therefore override the encodeURL behavior to perform /no/ URL
>> rewriting.
>>>
>>> Maybe one of the TC devs can tell us how to insert a Valve /before/ the
>>> AAA valves that are automatically set up by the security configuration
>>> in web.xml, but never explicitly defined using a <Valve> element
>> anywhere.
>>
>> Maybe look to see how it's implemented in v7.0 and hack something up.
>>
>> Taking Mark's hint and setting something on the Context, with effect on
>> StandardContextValve maybe...
>>
>>
>> p
>>
>>> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
I'm a bit lost with this thread. Are people suggesting I should submit a
patch. I really wouldn't know where to begin looking.
On Fri, Aug 20, 2010 at 7:47 PM, Pid <pi...@pidster.com> wrote:
> On 20/08/2010 17:35, Christopher Schultz wrote:
> > Pid,
> >
> > On 8/20/2010 8:33 AM, Pid wrote:
> >> On 19/08/2010 20:41, Wesley Acheson wrote:
> >>> On Thu, Aug 19, 2010 at 6:25 PM, Len Popp <le...@gmail.com> wrote:
> >>>
> >>>> On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
> >>>> <ch...@christopherschultz.net> wrote:
> >>>>> The servlet specification mandates this behavior. Tomcat simply must
> >>>>> support it. The spec says nothing of configurability, so Tomcat does
> not
> >>>>> provide any. Hence the need to write a filter to achieve your desired
> >>>>> behavior.
> >>>>
> >>>> That's not inviolable dogma. Tomcat does have some settings that make
> >>>> it operate out-of-spec, e.g. non-standard cookie parsing. I don't see
> >>>> why an option couldn't be added to disable JSESSIONID in URLs, if
> >>>> enough people would find it useful.
> >>>> --
> >>>> Len
> >>>
> >>>
> >>> Is there anywhere we could vote for such a feature? I know Resin has
> it as
> >>> I've stated before.
> >
> >> You could file an enhancement request in Bugzilla, but it would be more
> >> likely to get attention if it came with a patch. I can't comment as to
> >> whether it would be approved or not.
> >
> > This sounds like something that could easily be implemented as a Valve.
> > My understanding is that the only place where the jsessionid can't be
> > removed from URLs by a Filter is during the authentication process. A
> > Valve can be inserted /before/ the authentication/authorization Valve(s)
> > and therefore override the encodeURL behavior to perform /no/ URL
> rewriting.
> >
> > Maybe one of the TC devs can tell us how to insert a Valve /before/ the
> > AAA valves that are automatically set up by the security configuration
> > in web.xml, but never explicitly defined using a <Valve> element
> anywhere.
>
> Maybe look to see how it's implemented in v7.0 and hack something up.
>
> Taking Mark's hint and setting something on the Context, with effect on
> StandardContextValve maybe...
>
>
> p
>
> > -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Pid <pi...@pidster.com>.
On 20/08/2010 17:35, Christopher Schultz wrote:
> Pid,
>
> On 8/20/2010 8:33 AM, Pid wrote:
>> On 19/08/2010 20:41, Wesley Acheson wrote:
>>> On Thu, Aug 19, 2010 at 6:25 PM, Len Popp <le...@gmail.com> wrote:
>>>
>>>> On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
>>>> <ch...@christopherschultz.net> wrote:
>>>>> The servlet specification mandates this behavior. Tomcat simply must
>>>>> support it. The spec says nothing of configurability, so Tomcat does not
>>>>> provide any. Hence the need to write a filter to achieve your desired
>>>>> behavior.
>>>>
>>>> That's not inviolable dogma. Tomcat does have some settings that make
>>>> it operate out-of-spec, e.g. non-standard cookie parsing. I don't see
>>>> why an option couldn't be added to disable JSESSIONID in URLs, if
>>>> enough people would find it useful.
>>>> --
>>>> Len
>>>
>>>
>>> Is there anywhere we could vote for such a feature? I know Resin has it as
>>> I've stated before.
>
>> You could file an enhancement request in Bugzilla, but it would be more
>> likely to get attention if it came with a patch. I can't comment as to
>> whether it would be approved or not.
>
> This sounds like something that could easily be implemented as a Valve.
> My understanding is that the only place where the jsessionid can't be
> removed from URLs by a Filter is during the authentication process. A
> Valve can be inserted /before/ the authentication/authorization Valve(s)
> and therefore override the encodeURL behavior to perform /no/ URL rewriting.
>
> Maybe one of the TC devs can tell us how to insert a Valve /before/ the
> AAA valves that are automatically set up by the security configuration
> in web.xml, but never explicitly defined using a <Valve> element anywhere.
Maybe look to see how it's implemented in v7.0 and hack something up.
Taking Mark's hint and setting something on the Context, with effect on
StandardContextValve maybe...
p
> -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 8/20/2010 8:33 AM, Pid wrote:
> On 19/08/2010 20:41, Wesley Acheson wrote:
>> On Thu, Aug 19, 2010 at 6:25 PM, Len Popp <le...@gmail.com> wrote:
>>
>>> On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
>>> <ch...@christopherschultz.net> wrote:
>>>> The servlet specification mandates this behavior. Tomcat simply must
>>>> support it. The spec says nothing of configurability, so Tomcat does not
>>>> provide any. Hence the need to write a filter to achieve your desired
>>>> behavior.
>>>
>>> That's not inviolable dogma. Tomcat does have some settings that make
>>> it operate out-of-spec, e.g. non-standard cookie parsing. I don't see
>>> why an option couldn't be added to disable JSESSIONID in URLs, if
>>> enough people would find it useful.
>>> --
>>> Len
>>
>>
>> Is there anywhere we could vote for such a feature? I know Resin has it as
>> I've stated before.
>
> You could file an enhancement request in Bugzilla, but it would be more
> likely to get attention if it came with a patch. I can't comment as to
> whether it would be approved or not.
This sounds like something that could easily be implemented as a Valve.
My understanding is that the only place where the jsessionid can't be
removed from URLs by a Filter is during the authentication process. A
Valve can be inserted /before/ the authentication/authorization Valve(s)
and therefore override the encodeURL behavior to perform /no/ URL rewriting.
Maybe one of the TC devs can tell us how to insert a Valve /before/ the
AAA valves that are automatically set up by the security configuration
in web.xml, but never explicitly defined using a <Valve> element anywhere.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxurrYACgkQ9CaO5/Lv0PD18QCfa1cistS8pfMGe9mcZrWyOmBI
ybwAn2gAE7V/9I7vZIILB1h7hS2EZnWn
=9hMX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Pid <pi...@pidster.com>.
On 19/08/2010 20:41, Wesley Acheson wrote:
> On Thu, Aug 19, 2010 at 6:25 PM, Len Popp <le...@gmail.com> wrote:
>
>> On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
>> <ch...@christopherschultz.net> wrote:
>>> The servlet specification mandates this behavior. Tomcat simply must
>>> support it. The spec says nothing of configurability, so Tomcat does not
>>> provide any. Hence the need to write a filter to achieve your desired
>>> behavior.
>>
>> That's not inviolable dogma. Tomcat does have some settings that make
>> it operate out-of-spec, e.g. non-standard cookie parsing. I don't see
>> why an option couldn't be added to disable JSESSIONID in URLs, if
>> enough people would find it useful.
>> --
>> Len
>
>
> Is there anywhere we could vote for such a feature? I know Resin has it as
> I've stated before.
You could file an enhancement request in Bugzilla, but it would be more
likely to get attention if it came with a patch. I can't comment as to
whether it would be approved or not.
p
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
On Thu, Aug 19, 2010 at 6:25 PM, Len Popp <le...@gmail.com> wrote:
> On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
> > The servlet specification mandates this behavior. Tomcat simply must
> > support it. The spec says nothing of configurability, so Tomcat does not
> > provide any. Hence the need to write a filter to achieve your desired
> > behavior.
>
> That's not inviolable dogma. Tomcat does have some settings that make
> it operate out-of-spec, e.g. non-standard cookie parsing. I don't see
> why an option couldn't be added to disable JSESSIONID in URLs, if
> enough people would find it useful.
> --
> Len
Is there anywhere we could vote for such a feature? I know Resin has it as
I've stated before.
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Len Popp <le...@gmail.com>.
On Thu, Aug 19, 2010 at 12:01, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> The servlet specification mandates this behavior. Tomcat simply must
> support it. The spec says nothing of configurability, so Tomcat does not
> provide any. Hence the need to write a filter to achieve your desired
> behavior.
That's not inviolable dogma. Tomcat does have some settings that make
it operate out-of-spec, e.g. non-standard cookie parsing. I don't see
why an option couldn't be added to disable JSESSIONID in URLs, if
enough people would find it useful.
--
Len
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wesley,
On 8/19/2010 3:57 AM, Wesley Acheson wrote:
> We disabled both accepting of URL sessionId's and the session encoding
> URLs. Our application has worked well since with no problems. In fact
> better as we can cache certain pages in their entirity without being
> concerned with url rewriting. If we use relative URLs to static
> content served by Apache Httpd this now works too as otherwise Apache
> httpd gives a 404 (correctly) if there is a jsessionId in the URL.
Apache httpd's behavior is a matter of opinion at this point. I believe
it should /not/ give you 404s, but there are at least two workarounds
for that: mod_rewrite and mod_jk's StripSession setting.
> In my honest opinion the URL jsessionid thing is a bad idea. Its not
> even added as parameter to the URL but rather part of the request URL
> itself.
The HTTP/URL spec calls this a parameter: it's /not/ part of the path.
> So many websites don't function without cookies anyway. It
> would be just better to use session cookies or at least leave an
> option in server.xml or context xml to disable it.
The servlet specification mandates this behavior. Tomcat simply must
support it. The spec says nothing of configurability, so Tomcat does not
provide any. Hence the need to write a filter to achieve your desired
behavior.
> Imagine the following senario. Someone goes to malicious-site.com
> which has some javascript running in the background that posts to one
> of your forms. Card withdrawal for instance. This javascript can post
> all the details to your site, however it cannot write cookies for your
> domain. However if it was either able to "guess" a jessionid or one
> could have been used from somewhere else and jessionid is a parameter
> in the url theres nothing stopping them posting to
> http://yoursite/withdrawMoney;jsessionid=xxxxxxxxxxx.
What stops javascript from making a request to a site and adding headers
like, for instance the "Cookie" header? I haven't hacked around with
javascript capabilities so I really don't know if that's legal to do. I
would imagine that most web browsers have robust enough javascript
support that a telnet client could be written on them.
> Yes I know you need more security measures than that in place for this
> type of attack but I still believe that its valuable being able to
> disable it. Resin does allow you I wish tomcat would.
As is often said, patches are always welcome. ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxtVVwACgkQ9CaO5/Lv0PDMhACgtlf12f4RGKslsuNPUEFZujTK
1dAAoKZQWuZLBG4T543mzddDtHE3eWvI
=PBrQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
I was going to write this off list because its off topic, but maybe
the information is useful.
On Thu, Aug 19, 2010 at 5:19 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wesley,
>
> On 8/17/2010 6:05 PM, Wesley Acheson wrote:
>> I know of no better way to fix this. This is what we *had* to do to
>> pass PCI too so its no small deal.
>
> Wow, who made you disable jsessionids in URLs to achieve PCI compliance?
> Whoever did that doesn't understand Java webapp security. Or Internet
> security for that matter. :(
>
> Of course, there might just be some heavy-handed PCI requirements that
> the working group pulled out of their asses in a few minutes and then
> got on with a great deal of self-congratulations for making the Internet
> "safe".
>
> - -chris
It was a third party "ethical hacker", who's report we needed to be
clean for PCI. In general though I have to say I agree and the
;jsessionid thing is pretty insecure. Yes you can regenerate
sessionId's after a client logs in. (Though not in our case). Yes It
only appears on the first page if the user doesn't have cookies
enabled.
We disabled both accepting of URL sessionId's and the session encoding
URLs. Our application has worked well since with no problems. In fact
better as we can cache certain pages in their entirity without being
concerned with url rewriting. If we use relative URLs to static
content served by Apache Httpd this now works too as otherwise Apache
httpd gives a 404 (correctly) if there is a jsessionId in the URL.
In my honest opinion the URL jsessionid thing is a bad idea. Its not
even added as parameter to the URL but rather part of the request URL
itself. So many websites don't function without cookies anyway. It
would be just better to use session cookies or at least leave an
option in server.xml or context xml to disable it.
Imagine the following senario. Someone goes to malicious-site.com
which has some javascript running in the background that posts to one
of your forms. Card withdrawal for instance. This javascript can post
all the details to your site, however it cannot write cookies for your
domain. However if it was either able to "guess" a jessionid or one
could have been used from somewhere else and jessionid is a parameter
in the url theres nothing stopping them posting to
http://yoursite/withdrawMoney;jsessionid=xxxxxxxxxxx.
Yes I know you need more security measures than that in place for this
type of attack but I still believe that its valuable being able to
disable it. Resin does allow you I wish tomcat would.
Regards,
Wesley Acheson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wesley,
On 8/17/2010 6:05 PM, Wesley Acheson wrote:
> I know of no better way to fix this. This is what we *had* to do to
> pass PCI too so its no small deal.
Wow, who made you disable jsessionids in URLs to achieve PCI compliance?
Whoever did that doesn't understand Java webapp security. Or Internet
security for that matter. :(
Of course, there might just be some heavy-handed PCI requirements that
the working group pulled out of their asses in a few minutes and then
got on with a great deal of self-congratulations for making the Internet
"safe".
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxsorsACgkQ9CaO5/Lv0PAGzgCfXtTF9BFrRTGvrQ4YXd8ZjXqh
CFkAn39TkdK48bu5kItvxqoFrDHOgv5S
=s8g7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Posted by Wesley Acheson <we...@gmail.com>.
On Wed, Aug 18, 2010 at 12:01 AM, Scott Hamilton
<sc...@plateau.com> wrote:
> Using Tomcat 6.0.29, but I think this is version-independent (correct me
> if I'm wrong), at least for the 6.0.x versions.
>
>
>
> From what I understand (see
> http://randomcoder.com/articles/jsessionid-considered-harmful for
> instance - I also scanned various aspects of the tomcat source code)
> there is no way to disable tomcat from putting the JSESSIONID in URLs
> automatically with a nice friendly global switch/property. The only way
> I've seen how to do this, as suggested on the site I referenced, is to
> put into place a servlet filter.
>
>
>
> I'd like to know if I'm missing anything - is there a better way to do
> this?
>
>
>
> We have an app whose security is a concern for our customers, and
> JSESSIONIDs appearing in the URLs freak them out (especially when they
> demonstrate that you can get a URL from the app, email it to someone
> else, and have that person magically bypass authentication and assume
> the role of the other user - of course as long as the session is still
> valid).
>
>
>
> We are comfortable saying that in order to use our application you need
> to have cookies enabled, so I'm making the assumption that if we disable
> the feature of putting JSESSIONID into the URLs, either through a nice
> global switch or else a servlet filter, cookie-based session
> setting/tracking will still function just as we expect it.
>
>
>
> Finally, anyone know why this isn't already in the servlet spec? Seems
> like with more and more concern over web application security that this
> would be something the spec should address?
>
>
>
> Thanks,
>
> Scott
>
>
> .
> The information contained in this e-mail message is intended only for the personal
> and confidential use of the recipient(s) named above. This message is privileged
> and confidential. If the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you are hereby notified
> that you have received this document in error and that any review, dissemination,
> distribution, or copying of this message is strictly prohibited.
>
>
I know of no better way to fix this. This is what we *had* to do to
pass PCI too so its no small deal. However the filter does work
wondefully with minimal overhead.
Regards,
Wesley Acheson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org