#21231: Limiting the number of variables and files that a POST request can
contain
-------------------------------+--------------------------------------
Reporter: epandurski@… | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by tomchristie):
I agree that this is something we should be considering. Take the
following...
{{{
import time
from django.http import QueryDict
content = ('a=1&' * 2500000).rstrip('&')
d = QueryDict(content, encoding='utf-8');
}}}
That represents parsing a single valid 10MB URLEncoded POST request. On
my machine it consumes ~350MB and 100% CPU for ~30secs.
There's no built-in configurable protection in either Apache or Nginx
against that type of request without having also installed optional
plugins, and I'd consider `max_client_body_size = 10m` to be a perfectly
reasonable nginx setting.
I'll defer to the core dev team on this, but request parsing really does
seem to me to be the domain of the application to deal with, rather than
the server. For example, suppose you wanted the application to deal with
JSON requests that can contain base64 encoded file fields, or some other
content type that can contain a mix of file uploads and standard data -
the server has no way of parsing and inspecting if the requests are
malicious or not. As a further example - would we expect the server to be
responsible for parsing and validating against malicious XML payloads and
other content types that the application might parse?
FWIW, I believe that PHP includes
[http://stackoverflow.com/questions/8710185/new-limit-within-php-1000
-fields-per-post-does-someone-know-if-the-number-can built-in protection]
against this type of request, I've not managed to find information about
other languages/frameworks.
The simplest option would prob. be similar to the
`FORM_DATA_MAX_FIELDS_TOTAL_LENGTH` already noted, but perhaps tweak the
semantics slightly so that it's simply a setting specifying the maximum
allowable request size *excluding* any file upload parts
`REQUEST_MAX_DATA_SIZE` or similar. That'd allow the developer to
differentiate between the maximum allowable file upload size per-request,
and the maximum allowable in-memory data structures per-request.
--
Ticket URL: <https://code.djangoproject.com/ticket/21231#comment:15>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/078.e784dae4a7e1e82520d50c90418a3874%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
