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

net/http: multipart form parsing is hazardous and difficult to configure #58529

Open
neild opened this issue Feb 14, 2023 · 0 comments
Open

net/http: multipart form parsing is hazardous and difficult to configure #58529

neild opened this issue Feb 14, 2023 · 0 comments
Assignees
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@neild
Copy link
Contributor

neild commented Feb 14, 2023

http.Request helpfully parses multipart/form-data requests, not just explicitly in req.ParseMultipartForm but also implicitly in req.FormFile, req.FormValue, and req.PostFormValue.

Multipart form parsing uses mime/multipart.Reader.ReadForm, which has few limits on resource consumption:

  • ReadForm takes a maxMemory parameter, but will allocate up to 10MiB of memory over and above this limit.
  • ReadForm will write file form parts to disk, with no limit on the amount of disk consumed.

The defaults here are hazardous: A caller of req.FormValue may not intend to handle multipart/form-data forms at all, and will be surprised that the function can consume large amounts of memory and/or disk. The mechanisms for adjusting the defaults are inadequate: There is no simple way to disable multipart form parsing, to disable the use of disk temporary files, or to limit the memory consumption of ParseMultipartForm to less than 10MiB.

Compatibility may make it impossible to change the defaults, but at a minimum we should make it easy to configure reasonable limits.

@neild neild self-assigned this Feb 14, 2023
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

2 participants