tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wesley Acheson <wesley.ache...@gmail.com>
Subject Re: Is there a better way to disable JSESSIONID in the URLs?
Date Tue, 17 Aug 2010 22:05:22 GMT
On Wed, Aug 18, 2010 at 12:01 AM, Scott Hamilton
<scott.hamilton@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


Mime
View raw message