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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
