New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content-Disposition added for @ResponseBody methods explicitly mapped to ".html" or other extensions [SPR-13629] #18207

Closed
spring-issuemaster opened this Issue Nov 1, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Nov 1, 2015

Rossen Stoyanchev opened SPR-13629 and commented

The fix to protect against RFD exploits (#18124) 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.

spring-projects/spring-boot#4220 (comment)


Affects: 3.2.15, 4.1.8, 4.2.2

Issue Links:

  • #18222 Behavior change to Content-Disposition on @RequestMapping endpoint ("is duplicated by")
  • #18124 Protect against RFD exploits
  • #18164 Content-Disposition header causes download in browser for Spring Boot Actuator endpoints

Referenced from: commits f2e4da3, 237439e, d500d52, e190f26, 6a9329c, bdb71e9

Backported to: 4.1.9, 3.2.16

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 1, 2015

Rossen Stoyanchev commented

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.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 6, 2015

Rossen Stoyanchev commented

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").

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 6, 2015

Rossen Stoyanchev commented

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".

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Oct 17, 2018

blop commented

Can we disable this behaviour somehow ?
I'm not sure it's a good idea to assume every that HTTP client is be a web browser with all the security issues involved with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment