On Tue, Aug 31, 2010 at 9:09 AM, dave b <db.pub.m...@gmail.com> wrote: >>> Secure by default please! >> >> That's an easy epithet to throw around, but I disagree that it is >> appropriate here. "Security" doesn't mean "stops the user from making >> mistakes". > > Look like wsgi, apache2 and django all on ubuntu PLACE no size limits > at all by default. Isn't that neat? > I think debian is the same too! > Seriously, are you silly enough to think I was just using the > development server for testing? > Do not pass go do not collect profit! > > > >> it by default (i.e., no size limit). However, this relys on people >> reading the documentation and determining an appropriate value for the >> setting -- at which point, we've just duplicated the functionality of >> Apache without actually changing anything. > > Incorrect. Put it in the changelog etc. > I meant people are supposed to know about apache and its setup surely > they should read the changelog when django changes? right. > >> IMHO, Graham is completely right when he says that the webserver is >> the right place to catch this. Django isn't about to start introducing >> more settings to duplicate functionality that is better provided by >> other parts of the tool chain. > > I disagree. Very much so. Stop saying this isn't a django issue and > start fixing it. > >> That said, there has been discussion recently about adding a section >> to Django's docs talking about security issues -- things that may not >> be immediately obvious about project design and configuration, but >> would behoove users to think about. A discussion of this problem >> sounds like it would be a good addition. > > Look you guys are saying that django is secure and then not willing to > say "ok django might want to do something here". That's a great idea! > >>> Ok still following? >> >> Look -- Graham may not use Django on a daily basis, but he's not a >> fool. For the record, neither am I. A cursory examination of his >> history on this mailing list would indicate that saying "Add a >> FileField uploading to /tmp to an existing model" would be more than >> enough detail to describe your setup here. >> >> The part of this problem that you continue to refuse to describe is >> *THE ONLY PART THAT MATTERS* - the web server configuration that >> you're using to make your assertion. > > > The default wsgi apache2 setup on $distro is a good testing place for > this if you want to test how people will likely have it setup, or was > said to me in prior emails here. I have tested it against that setup > of course and *against* *many* others. > > > >>> apache setup etc.). >> >> The implication here is that you *haven't* tried this with Apache. >> Worse still, it sounds like you might be trying to use the Django >> development server as your test case to validate that this is a >> problem. > > I can assure you I have tested this against apache2 with wsgi running > with django. > > >>> What do you say to this ? >> >> I say that this is the reason we're getting frustrated. > > Put your hands up in the air like you just don't care! > >> So far, you haven't actually told us which web server you *are* using. >> You keep alluding to this "not-apache" webserver, but you haven't >> actually said which webserver you *are* using. > This doesn't even matter here, my attack works against the default > apache wsgi and django setup K THX BIA. > >> Apache has it's faults, but it is feature complete, battle hardened, >> widely available, and almost certainly the most widely used webserver >> for Django deployment. It's also the webserver that virtually every >> Django user and developer will have some experience in using. If a >> potential problem exists in at the server level, Apache is the best >> lingua franca to use in demonstrating it. > > Done that :) > blahblahblalbha sssh listen. No Of course I have tested it against that. > How confident are you in that in every possible setup for django used > in production, this issue isn't a problem? > >> If the problem is actually that you're using a custom HTTP server, and >> that custom HTTP server isn't providing a feature that you need (such >> as a way to reject large uploads) > > Look. Should I post this to somewhere more security related on the internet?
Do whatever floats your boat. Graham and I have both explained the situation. If anyone asks the same questions, we'll give them the same answer. > Summary: > In the default setup of wsgi, apache and django (on distributions like > ubuntu and debian) by default there are no limits on the size of a > file that an attacker can upload. > http://cwe.mitre.org/top25/#CWE-770 and see example 2 at > http://cwe.mitre.org/data/definitions/770.html One last try for your benefit: If you have your Apache install configured to accept arbitrarily sized uploads, your Apache install will accept arbitrarily sized uploads. This should not be surprising behavior. If Debian or Ubuntu are packaging Apache with this as the default behavior, that's an issue for Debian and Ubuntu to manage. This doesn't make *Django* insecure -- it makes the default install of *Apache* insecure on those platforms. *Any* application deployed using *any* framework would be subject to the same attack. And the attack can be completely avoided by correctly configuring Apache. And, for the record, the fact that Ubuntu or Debian have chosen these defaults doesn't make Apache insecure either. System defaults exist to make it easy and obvious to get something started. A responsible sysadmin for a public-facing webserver shouldn't be using *any* OS-provided defaults without auditing them. To aid that process, the Django project is in a position to describe the sorts of issues that a sysadmin should watch out for; hence, documenting deployment-related security issues such as this one is in scope. However, at the end of the day, as Graham and I have *repeatedly* told you -- this is an issue that should be caught at the webserver, not at the application level. Even if we weren't talking about duplicating functionality (and we are), there are both practical and technical reasons why it is inappropriate for Django to implement file-upload size restrictions. This problem can be avoided with appropriate configuration of your web server, and therefore should be. Yours, Russ Magee %-) -- 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.
