Skip to content
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

Skip Content-Disposition header when requestUri is the context and/or the servlet path [SPR-13612] #18190

Closed
spring-projects-issues opened this issue Oct 27, 2015 · 2 comments
Assignees
Labels
in: web status: duplicate

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 27, 2015

Rossen Stoyanchev opened SPR-13612 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.

However if you name an application with Maven conventions my-app.1.3.4-SNAPSHOT and deploy to a servlet container a Content-Disposition header is added for the URLs that match the context and/or servlet path.


Affects: 4.1.8, 4.2.2

Issue Links:

  • #18165 Skip Content-Disposition header when status != 2xx ("duplicates")
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 27, 2015

Rossen Stoyanchev commented

Stock Spring Boot app from start.spring.io with artifact=demo-app.1.3.4-SNAPSHOT does return a 404 with Content-Disposition for /demo-app.1.3.4-SNAPSHOT. That's fixed with #18165 however. I confirmed this by switching to a Spring Boot 1.3.0 snapshot. Also note that the same URL with a slash at the end is not affected to begin with (it's only a dot in the last path segment that triggers this).

For a non-Spring Boot app the issue not reproducible. The URL /demo-app.1.3.4-SNAPSHOT returns 302 while for /demo-app.1.3.4-SNAPSHOT/ it depends on the mapping for "/". If mapped to a home HTML page there is no issue since we only add Content-Disposition for response body rendering.

So the only way I see this being a potential issue is if there is @ResponseBody rendering for the context path URL. At that point this is probably not meant for rendering in a browser anyway while a home HTML page wouldn't have the issue to begin with.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 27, 2015

Rossen Stoyanchev commented

Resolving this as duplicate of #18165 Phil Webb let me know if you've have something different from what I described.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web status: duplicate
Projects
None yet
Development

No branches or pull requests

2 participants