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

Multipart Upload with Commons Fileupload on lazy mode downloads data on cleanup [SPR-16640] #21181

spring-projects-issues opened this issue Mar 26, 2018 · 1 comment
in: web status: backported type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Mar 26, 2018

Steven Peh opened SPR-16640 and commented

Using Spring Boot v2.0.0
Apache Commons FileUpload v1.3.3

When set to resolveLazily, Spring boot will not parse the multipart request and download to local temp folder until needed. This works as expected, however if the app subsequently cancels the intent to accept the upload request, i.e. after applying authorization checks and the connection request is not authorized, during the clean up phase, Spring Boot actually initializes the multi-part to download the data so that it can cleanup.

Here's the chain of execution, all within spring boot code base:

CommonsMultipartResolver .cleanupMultipart() {
-> AbstractMultipartHttpServletRequest.getMultipartFiles() {
if (this.multipartFiles == null) { <-- this will be true when resolveLazily is set
initializeMultipart(); <-- here's the culprit
The initializeMultipart will invoke parseRequest(..) to download the multipart upload data on cleanup which doesn't make sense when we have set resolveLazily and we have rejected/cancel the request for various reasons (access control being one of them).

Its also a cyber security issue here as unauthorized requests can upload arbitrary data, though only temporarily it can still be a very large file that use up storage, to the server.

Affects: 4.3.14, 5.0.4

Issue Links:

  • #7471 Support MultipartFile-array property

Referenced from: commits 10cb2cc, c1cb031

Backported to: 4.3.15

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 26, 2018

Juergen Hoeller commented

We explicitly check whether the multipart request has been resolved at all now, in CommonsMultipartResolver as well as StandardServletMultipartResolver, before trying to perform a cleanup.

@spring-projects-issues spring-projects-issues added type: bug status: backported in: web labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.0.5 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: web status: backported type: bug
None yet

No branches or pull requests

2 participants