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