Dejan Bosanac added a comment - 05/Apr/12 02:59 PM

Dejan Bosanac added a comment - 05/Apr/12 02:59 PM I think this is not a problem. 302 status simply means / is at /index.html ... if you tweak test a bit and use http://0.0.0.0:8161/demo/index.html url (or any other valid demo or admin url), you'll get a proper 405 status.

Dave Stanley added a comment - 05/Apr/12 03:11 PM - edited

Dave Stanley added a comment - 05/Apr/12 03:11 PM - edited This is a follow on to a similar issue with camel - main driver for fix was http://www.kb.cert.org/vuls/id/867593

Dejan Bosanac added a comment - 06/Apr/12 10:38 AM - edited

Dejan Bosanac added a comment - 06/Apr/12 10:38 AM - edited Hi Dave, I did some more research on this. This has nothing to do with Spring or any of the Servlets, this is purely how Jetty handles TRACE requests. And it can be interpreted in different ways, but it could be argued that this is a proper behavior. So demo app doesn't include any servlets from our side and is purely a set of client (http/js) examples. So some web servers probably intercept any TRACE calls and return error 403,405 or some 5xx status. Others first resolve the url fully and only if the URL is valid return TRACE disabled status. Jetty do this, so for example if you try http://0.0.0.0:8161/demoqwe you'll get 404 as this URL doesn't exist. The url used in test http://0.0.0.0:8161/demo requires for Jetty to do a redirect to http://0.0.0.0:8161/demo/ and hence the 302 status code. If the security tool follow this new URL it will get 405 as expected. There's even a blog post from a guy that's into this PCI compliant testings http://blog.techstacks.com/2008/10/consolidated-post-trace-method-handling.html and you can see that he discusses this case, so it's probably common. We can raise issue against Jetty and I can even patch it if needed. but it'd be good to first communicate this with the customer,

Dave Stanley added a comment - 18/May/12 03:26 PM

Dave Stanley added a comment - 18/May/12 03:26 PM Closing for now.