|
As of October 27th, please open all new issues in the Red Hat Customer Portal . |
|
[
Permlink
| « Hide
]
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
This is a follow on to a similar issue with camel - main driver for fix was http://www.kb.cert.org/vuls/id/867593
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 you'll get 404 as this URL doesn't exist. The url used in test requires for Jetty to do a redirect to 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, |
||||||||||||||||||||||||||||||||||||||||||