On 8/30/2010 9:09 PM, dave b 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!
> 
Talking that way to Russell Keith-Magee just makes you look like a
troll. If you think there is even a possibility that he is that silly
then you are clearly sadly deluded. Russell is well know throughout the
Django community (and outside it) for his deep understanding of the
issues and compromises involved in building a professional web framework.

You, on the other hand, are a complete unknown who has walked in off the
street and started to make a lot of noise. All this has achieved is to
demonstrate your total incomprehension of how to achieve practical
results, which despite your focus on only the technical issues that
interest you involves knowing how to interact with people as well.

It's kind of cute that you appear to think you might be smarter than me
(though you certainly don't have as much experience, and frankly I think
I would be likely to win in sheer sex appeal too). It's sheer lunacy to
think you might be smarter than Keith-Magee and Dumpleton (though you
may *just* beat Graham on people skills, he has the definite advantage
that he has demonstrated he knows what he's talking about).
> 
> 
>> 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.
> 
Who are you to tell the Django developers what to be doing? If you have
a demonstrated public record of making sound engineering decisions that
resulted in well-constructed systems, *then* your opinion might count
for something. You don't just need brains, you need to now how to use
them as well.
> 
>> 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.
> 
Sigh. It has already been clearly explained to you that the default
installation of anything isn't a reliable way to measure a platform's
fitness for purpose. If you want to run a production server on the
default installation of Apache how far do you think you will get?

The point is, serious people with serious production problems well
understand the issues that can come up, and the don't expect that the
products they use will meet their needs out of the box.

Go to Google and look up the phrase "one-trick pony". That's where I
have you filed right now.
> 
> 
>>> 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.
> 
But still you refuse to show us the results? That seems a bit perverse.
> 
>>> 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!
> 
It isn't our responsibility to understand your drivel. Make sense or
stop making this noise.

>> 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?
> 
I don't know about Keith, but I am pretty confident that the Washington
Post, the New York Times, and all the rest of the large organizations
that rely on Django for their daily bread wouldn't consider your output
worth $30 an hour. Please read people's replies more carefully.

>> 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?
> 
Frankly, at this stage you can stick it up your ass and set fire to it
as far as I'm concerned. I like to delude myself that I am pretty
tolerant, but an ego the size of yours rubs me up the wrong way and I
start to forget my manners.

> 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
> 
Summary:

If you are stupid enough to run a production web server on the default
setup of wsgi, apache and django when you are serving more than 5,000
impressions a day you are an idiot who will never deserve gainful
employment in the web world.

How many hits a day does your site get?

Look, get off your high horse. Stop trying to prove to everyone how
clever you are, join the community and start to seriously learn from the
many bright people who regularly contribute to this list (which is why I
hang out here. As I learn, I also try to answer a few questions,
sometimes wrongly, to take the strain off the guys who've been doing it
since I joined, and before).

If you can do that, this episode will blow over and soon you will be as
welcome as everyone else. Carry on like you are doing and people will
start to run the other way at the sight of your name.

regards
 Steve
> 
> 
> --
> Conscience doth make cowards of us all.               -- Shakespeare
> 
A fool thinks himself to be wise, but a wise man knows himself to be a
fool.                                              -- also Shakespeare

PS: Since you are such a stickler, try adding a space to the double dash
that delineates your sig block. That way sensible mailers won't try and
quote it as part of your message.
-- 
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.

Reply via email to