Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-13629

Content-Disposition added for @ResponseBody methods explicitly mapped to ".html" or other extensions

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 3.2.15, 4.1.8, 4.2.2
    • Fix Version/s: 3.2.16, 4.1.9, 4.2.3
    • Component/s: Web
    • Labels:
    • Last commented by a User:
      false

      Description

      The fix to protect against RFD exploits (SPR-13548) introduced a "Content-Disposition:attachment;filename=f.txt" response header for @ResponseBody methods where the URL appears to have an extension that is neither whitelisted by default nor explicitly registered by the application.

      By default ".html" is not whitelisted since a controller method returning String can be rendered as any requested content type (since StringHttpMessageConverter accepts "/") and in the case of HTML that can lead to XSS and RFD attacks.

      However as commented under Spring Boot #4220 we should consider ways to make it straight-forward to render HTML via @ResponseBody when that is the actual intent.

      https://github.com/spring-projects/spring-boot/issues/4220#issuecomment-152812708

        Issue Links

          Activity

          Hide
          rstoya05-aop Rossen Stoyanchev added a comment - - edited

          There is some very good feedback under the Boot ticket 4220.

          While it's reasonable not to whitelist "html" by default (thus exposing controller methods returning String) we can also eliminate the need to explicitly register ".html" for content negotiation purposes. For example if the mapping includes ".html" or has a produces condition we shouldn't need anything further.

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - - edited There is some very good feedback under the Boot ticket 4220. While it's reasonable not to whitelist "html" by default (thus exposing controller methods returning String) we can also eliminate the need to explicitly register ".html" for content negotiation purposes. For example if the mapping includes ".html" or has a produces condition we shouldn't need anything further.
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment -

          Re-opening and updating the title to a reflect a more general aim to fix this for any extension that's explicitly present in the mapping (not only ".html").

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - Re-opening and updating the title to a reflect a more general aim to fix this for any extension that's explicitly present in the mapping (not only ".html").
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment -

          This now works so that any extension explicitly present in a request mapping is okay. Furthermore, specifically for ".html" in the URL we do allow suffix pattern matching if the method explicitly states that it produces "text/html".

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - This now works so that any extension explicitly present in a request mapping is okay. Furthermore, specifically for ".html" in the URL we do allow suffix pattern matching if the method explicitly states that it produces "text/html".

            People

            • Assignee:
              rstoya05-aop Rossen Stoyanchev
              Reporter:
              rstoya05-aop Rossen Stoyanchev
              Last updater:
              St├ęphane Nicoll
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 16 weeks, 1 day ago