Uploaded image for project: 'FUSE Message Broker'
  1. FUSE Message Broker
  2. MB-1107

Broker Web Console should disable HTTP TRACE by default

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 5.5.1-fuse-02-02
    • Fix Version/s: 5.5.1-fuse-07-11
    • Component/s: broker
    • Labels:
      None
    • Environment:
      Fuse MB 5.5.1-fuse-02-02
    • Similar Issues:
      Show 10 results 

      Description

      This is a follow on issue to MR-579.

      If you hit http://0.0.0.0:8161/demo with a HTTP TRACE it responds. It should be disabled by default.

        Gliffy Diagrams

          Activity

          Hide
          dbosanac Dejan Bosanac added a comment -

          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.

          Show
          dbosanac Dejan Bosanac added a comment - 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.
          Hide
          davestanley Dave Stanley added a comment - - 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

          Show
          davestanley Dave Stanley added a comment - - 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
          Hide
          dbosanac Dejan Bosanac added a comment - - 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,

          Show
          dbosanac Dejan Bosanac added a comment - - 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,
          Hide
          davestanley Dave Stanley added a comment -

          Closing for now.

          Show
          davestanley Dave Stanley added a comment - Closing for now.

            People

            • Assignee:
              dbosanac Dejan Bosanac
              Reporter:
              davestanley Dave Stanley
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: