On 8/29/2010 12:05 AM, dave b wrote: > On 29 August 2010 13:33, Graham Dumpleton <graham.dumple...@gmail.com> wrote: >> >> >> On Aug 29, 1:17 pm, dave b <db.pub.m...@gmail.com> wrote: >>> On 29 August 2010 08:28, Steve Holden <holden...@gmail.com> wrote: >>> >>>> On 8/28/2010 6:10 PM, Graham Dumpleton wrote: >>>>> On Aug 28, 11:21 pm, dave b <db.pub.m...@gmail.com> wrote: >>>>>>>>> So obviously my proposed attack is to simply say "content length is >>>>>>>>> tiny" and "this file is actually HUGE". >>>> [...] >>>>> All up, I would suggest you are getting worked up over nothing. >>>> +1 >>> >>> Yes I have :) it "works for me tm". >>> Also, you have to consider the other problem. If the file is > 2.5 mb >>> it can be put in /tmp and this has no size limits which again is going >>> to make the system slower and can be used to attack it? in either case >>> there seem to be real protections against this in django core as far >>> as I can see. >> >> Use Apache/mod_wsgi and you can say: >> >> LimitRequestBody 1000000 >> >> and Apache/mod_wsgi will give back a HTTP_REQUEST_ENTITY_TOO_LARGE >> error when it goes over that size before it even passes the request to >> Django and even before any of the request content is read by Apache. >> >> So, add the protections where most appropriate if you want to outright >> block requests with large content. If your issue is efficient handling >> of large posts, where you do want to handle them, then that is an >> issue for Django. >> >> Note that other Apache modules by which you can host Django may not >> work properly in honouring LimitRequestBody directive of Apache. The >> mod_python module for example doesn't really get it right, causing an >> exception when request content tries to be read by Django application, >> resulting in a malformed error response. > > Yes I understand that both apache and some the mods have limits. > However, this doesn't stop a persistent attacker abusing these > relatively high limits. > IMHO I feel that django should be able to put a cap on the largest > size temporary file size possible. In addition, /tmp is a fine place > to store temporary files if the size may not be known. > > I propose the following in psudo code: > > 1. start reading the file if we are receiving it (regardless of the > default 2.5 mb limit) > 2. once it goes over 2.5mb / the configured default shift to the next > available storage option. > > In addition, as you are pointing out that it is really not possible > for django to handle chunked requests and the content length field > must be specified then you should have no problems with the following > patch (in either case this is safe because by default it will revert > back to the temporary file storage) : > > > --- django/core/files/uploadhandler.py.orig 2010-08-29 13:50:17.000000000 > +1000 > +++ django/core/files/uploadhandler.py 2010-08-29 14:01:15.000000000 > +1000 > @@ -153,7 +153,7 @@ > """ > # Check the content-length header to see if we should > # If the post is too large, we cannot use the Memory handler. > - if content_length > settings.FILE_UPLOAD_MAX_MEMORY_SIZE: > + if content_length is None or content_length > > settings.FILE_UPLOAD_MAX_MEMORY_SIZE: > self.activated = False > else: > self.activated = True > @@ -170,6 +170,7 @@ > """ > if self.activated: > self.file.write(raw_data) > + self.file.truncate(settings.FILE_UPLOAD_MAX_MEMORY_SIZE) > else: > return raw_data > > http://pastebin.com/5vgGMb5z > OK, so you don't believe the advice you are getting, which is that of the many issues a Django sit will face this is a relatively low probability attack. That's fair enough - a vulnerability is a vulnerability, after all, no matter how improbable, and not everyone will set up their production systems to be correctly protected by a front-end server.
If you really want to see this in Django you would be better advised to post it in the issue tracker, where it will not get lost. regards Steve -- DjangoCon US 2010 September 7-9 http://djangocon.us/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
