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 Thu, 19 Aug 2010 07:57:18 GMT
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
<chris@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


Mime
View raw message