DRF structure query

[Dave B]

Hi,

Being fairly new to DRF, I'm just wondering on the best ways of going about 
stucturing an api which has man endpoints.

Basically is there a good reason not to put different categories of 
endpoints together in different apps, like the ones for user data, ones for 
app data etc.

And then how does that work with the routers?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20f43bb4-f73f-428a-8628-338e81b2da86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to insert a csrf_token when entering datas through a bot ?

[dave b]

On 12 April 2011 22:09, JustinMarsan  wrote:
> Hello,
>
> What would be the best way to allow some bots to POST some content to
> a website. Without crsf_token, the bot will get a 403, and I would
> prefer not to remove this behavior but rather find a way to make the
> bot send a token. How could I do that ?
>
> I was thinking of making sure the bot is authorizied to post with some
> identifiers but I guess there might be a better way to do this using
> the built-in token system.
>
> Any ideas ?
>

Why can't you make your bot csrf token aware ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Advice: project hosting apps

[dave b]

There is also http://gitorious.org/ - it is ROR, but it is agpl.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Cool and useful development commands :-)

[dave b]

On 24 February 2011 00:29, Simone Federici  wrote:
> Maybe you could write a filter "urlsafe" to use into templates so that
> variable does not contains javascript.
> And you could create a command that scan templates and raise an alert every
> variable inside an href attribute that is not "urlsafe".
> But I believe that a tool is used to work, not to do the work for me. And
> Django is a tool.
> It's like the java paradox,  java is a language that hidden a lot of
> problems, and try to resolve them without the programmers. Result: you
> cannot trust a java programmer, because often he doesn't know what the code
> really does.
> For this reason, I see that this kind of problems are better if you leave
> resolve by developers. The better solution is to document better the
> problem.
> I think it is out of the scope of djangodevtools.
> In other words, djangodevtools not is a library to development, but is a
would

That sounds like a good idea  -- "urlsafe".  There already is urlize.
However, it doesn't work for all urls. I was thinking about using
xpath to evaluate the use of variables in 'interesting' places
(attributes) and then checking if the attribute is quoted or not. I
think someone with more django template knowledge can think of a
better way.

I also reported http://code.djangoproject.com/ticket/15365
so now it might be worthwhile searching for markup use in templates.

The best python html sanitization I have so far seen is from from
lxml.html.clean[0]. However it seems to be very much on the too
'strong' side.

[0] - http://lxml.de/lxmlhtml.html#cleaning-up-html

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Just going to point this out ...

[dave b]

It would be interesting to perhaps extend something like django-lint
to pick up on what could be mistakes in templates.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Just going to point this out ...

[dave b]

>
> is this what you're looking for?
>
> http://www.owasp.org/index.php/OWASP_Application_Security_FAQ
>
> Mike

Hi Mike. Well in this case the page would be
http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
 but yes that link is a good starting point.

I should clarify why I emailed this list --> I emailed this list
instead of filing a bug because I thought this was a bit stupid to
file a bug for. I wanted to see what other 'users' thought about it.
The general opinion thus far has been that people _should_ know about
these problems which is a nice assumption but imho not always true
(and in a fair amount of applications no one will care if an xss is
possible).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Just going to point this out ...

[dave b]

> Which of course it can't - it is properly escaped.
>
> Cheers
>
> Tom
>

Yes.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Just going to point this out ...

[dave b]

On 19 February 2011 01:36, Masklinn <maskl...@masklinn.net> wrote:
> On 2011-02-18, at 15:31 , dave b wrote:
>> On 19 February 2011 01:29, Shawn Milochik <sh...@milochik.com> wrote:
>>> By the way -- I realized what happened. You CC'd me on the e-mail to the 
>>> list. So when I replied it went directly to you.
>>
>> Ah sorry about the mix up then!
>> Yeah :P
>>
>> My view on this is that documentation can always be improved !
> Sure, but the way to do it is usually to open a bug on the tracker and 
> provide a documentation patch (or alternatively find a way to fix the issue 
> itself, but as far as I can tell if you're putting unchecked unvalidated data 
> in your links there isn't much that can be done to help you).

Um, no I am not. I was using href with javascript as an example.

Example for Cal:

views.py
from django.shortcuts import render_to_response

def show_lol(response):
   return render_to_response("lol.html", {"lol" :
"javascript:alert(document.cookie)"} )

lol.html


   

OKOKOKOK
   



Yes this is very contrived.
If you used a URLField and the validator runs - this will not be saved
in the first place. Please do keep in mind that this is just a dumb
example of attribute abuse.
(./sleep &) Sorry I am very tired atm - it isn't attribute injection -
just abuse.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Just going to point this out ...

[dave b]

On 19 February 2011 01:29, Shawn Milochik  wrote:
> By the way -- I realized what happened. You CC'd me on the e-mail to the 
> list. So when I replied it went directly to you.

Ah sorry about the mix up then!
Yeah :P

My view on this is that documentation can always be improved !

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Just going to point this out ...

[dave b]

On 19 February 2011 01:19, Shawn Milochik  wrote:
> Don't take my comment as a personal attack. I was just pointing out that 
> injection attacks are one of those things we're all responsible for being 
> aware of and not opening ourselves up to.
>
> To the extent that Django protects us from such things, it's generally to 
> ensure that the boilerplate Django saves us from writing (by baking it in) is 
> safe.
>
> My point is that using Django doesnt relieve us of the responsibility of 
> knowing what we're doing.
>
> Shawn

Oh how nice you sent this to me off the list?

Ok great. How about you get off your damn high horse and settle with
us mortals ?

Wait a second when I read your email it sounds like you accept the
fact that people "should know what they are doing" ... but you didn't
answer my question or _suggest_ that some minor note be added to the
template documentation.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: Just going to point this out ...

[dave b]

 On 19 February 2011 00:57, Shawn Milochik  wrote:
> I also didn't see the part where they state that you shouldn't put your
> database login information in a template. That's probably because Django is
> designed to allow Web developers to do their jobs more easily, not allow
> people who don't know what they're doing make Web applications. If you're
> going to do something really stupid then blame Django in some way, then
> you're probably not competent at the job.

Um. While it might be obvious to us it might not be so obvious to others.
So this comment,
" If you're going to do something really stupid then blame Django in
some way, then  you're probably not competent at the job" shows a lack
of thought  for other users given the way the django documentation
found at [0] is presented.

[0] - 
http://docs.djangoproject.com/en/dev/topics/templates/#automatic-html-escaping

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Just going to point this out ...

[dave b]

Hi I cannot see where in the django documentation it states that you
shouldn't do something like this:
  ** (as an example of a potential
attribute injection vector[0] - where you are not using a URLField or
failure to call full_clean (on a URLField) ).
That is I cannot see where django states that 'oh by the way our
autoescape isn't safe in a few cases' and 'you should watch out for
attribute injection!'.

So did I miss it?

[0] - the user-controlled link could be javascript:alert(1)



--
The fashion wears out more apparel than the man.-- William
Shakespeare, "Much Ado About Nothing"

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: South - when to start?

[dave b]

On 18 February 2011 21:24, Piotr Zalewa  wrote:
> Where is the best moment to start with south?
>
> 1. The very beginning, as the first app added to the project?
> 2. At the moment when more devs will be involved?
> 3. When real data will start to show?
>

now!
(just start using it!)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Re: potential issue re in memory django file uploading.

[dave b]

Ok no movement :)


Lighttpd has a default limit of 2gb, cherokee seems to have the same.
Pin it on the httpd all you like - but the default apache has no limit
(0 - unlimited :) ).
http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody

--
The better part of valor is discretion. -- William Shakespeare, "Henry 
IV"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

> His response is to say he will escalate this to some other security
> forum. We can only assume that this is a threat that he will raise
> merry hell until we do what he says.

Right first: Yes I am sorry for the 9 or so posts :)  I am only human.
Right. Um no that's not a threat.
That's being responsible imho, instead of just those looking at
django-users, others will now also know about the problem. Knowing
about the problem, they can apply a workaround or fix.
Do remember, fix it anyway you like, the problem still exists.

> Our intention is not to make anyone feel stupid. As I've said
> previously, we take security seriously. However, extraordinary claims
> require extraordinary proof. When software X uses web server Y, and Y
> explicitly provides settings to avoid the specific problem you're
> describing, and your "attack" is predicated on those settings not
> being used in your use of Y, it's hard to make the case that you've
> found a security hole in X. You have, at best, found a weakness in the
> default configuration of Y on a specific platform -- which is exactly
> what we've told you.

I am not about to see what the default are on other commonly used
platforms, that is a total waste of my time.
http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody (the
default is 0).
Apparently LimitRequestBody is not touched by mod_wsgi so I assume
this means the default remains 0, unlimited.


> As for our claim that you should be auditing the settings of the
> software you use -- I'm unapologetic about that. Default values on any
> platform are selected to provide maximum utility for the general case,
> not maximum utility for a specific case.

I am going to suggest
1. this is fixed in django (through a default size limit)
and
2. wsgi sets the default LimitRequestBody to be a sane value.
As Graham Dumpleton[0] does a lot of work on mod_wsgi. So perhaps he
can introduce this into mod_wsgi.

This will mean that
1. django running in different configurations will be protected.
2. other python programs will be protected to a degree (under mod_wsgi).

Also, Graham Dumpleton keep up the good work on mod_wsgi!

[0] http://code.google.com/p/modwsgi/source/list
--
Talkers are no good doers.  -- William Shakespeare, "Henry VI"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

On 31 August 2010 12:04, Russell Keith-Magee <russ...@keith-magee.com> wrote:
>> On 8/30/2010 9:09 PM, dave b wrote:
>>> Do not pass go do not collect profit!
> ...
>>> Put your hands up in the air like you just don't care!
> ...
>>> blahblahblalbha sssh listen.
> ...
>
> On Tue, Aug 31, 2010 at 9:42 AM, Steve Holden <holden...@gmail.com> wrote:
>
>> 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.
>
> Ok - before tempers get out of control, let's nip this in the bud.
>
> I don't care if the your weapon of choice is passive-aggressive
> expressions of pop culture, or detailed explorations of the
> appropriate application of incendiary products to bodily orifices --
> this kind of tone doesn't cast the community in a good light.
>
> We try to maintain a civil tone here. If you don't feel that you're
> able to maintain that tone, please walk away from this discussion.

Agreed, I apologize for my part in this.
Just a heads up have sent an email to bugtraq with this little issue
outlined in it.
While you wait for it to go through moderation here are some quotes
from much smarter people than myself:

"Those who cannot learn from history are doomed to repeat it."
"History is written by the victors. "
' "No comment" is a splendid expression. I am using it again and again. '
"Given enough eyeballs, all bugs are shallow. "

--
My only love sprung from my only hate!Too early seen unknown, and
known too late! -- William Shakespeare, "Romeo and Juliet"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

> 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.

> 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.
Ok look. I am trying to be a nice guy here. You are making my job
harder than it should be.
Fact I reported a potential security bug, which did have the incorrect
description(sort of ;) ) at the start but then I have provided a clear
summary of the issue.

So let me tell you a story. A guy reports a bug to the django security
email, he gets a vacation reply. So he asks on irc in #django where he
should take the issue to next, he is told the django users mailing
list.
So he emails the list and they don't take him seriously. They claim
that the problem is that people shouldn't be using the default
webserver configurations. They claim the problem isn't our fault. They
also claim that the guy thinks he is smarter than others. They claim
that this guy is wrong because in the "real" world people don't use
defaults without auditing *all* of them right?

I can tell you that this guy feels really stupid right now.

Here something from the default php5 setup on debian(for apache).:
; Maximum size of POST data that PHP will accept.
post_max_size = 8M
...
; Maximum allowed size for uploaded files.
upload_max_filesize = 2M


; Maximum number of files that can be uploaded via a single request
max_file_uploads = 50


--
How apt the poor are to be proud.   -- William Shakespeare, 
"Twelfth-Night"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

>
> From my testing (granted this was run against something pre-1.2 so things
> may have changed since then), as soon as you initiate the first file upload,
> you're monopolizing the devserver process, preventing further attempts to do
> the following 9 uploads until the first has completed (successfully or
> aborted).
>
> Not that you'd want to use devserver in a production environment anyways, as
> Russell points out in the documentation[1].  Note the "DO NOT USE THIS
> SERVER IN A PRODUCTION SETTING."  It's not very subtle about that. :)

Exactly!
So test against wsgi and apache2 ;)


--
There's small choice in rotten apples.  -- William Shakespeare, "The
Taming of the Shrew"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

>> 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?

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



--
Conscience doth make cowards of us all. -- Shakespeare

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

/me rolls eyes.
You have a valid point re /tmp, sorry I am used to mounting /tmp as
/tmpfs - my mistake :)
Ok lets be *really* clear the security problem still exists.
An attack can in the limits set on the maximum post by the httpd /
module in use upload a large file.


> I don't actually use Django so not 100% sure, but yes there possibly
> isn't an equivalent of LimitRequestBody definable within Django unless
> can be done with middleware.

Ok so you don't even use django, ok...
You know I think I missed your presentation at pycon-au.

>
> So, yes it may make sense for Django to have a fail safe and allow you
> to specify a maximum on upload size if it doesn't already, but that is
> only of use where you haven't set up your production web server
> properly to protect you from abuses, something you should be doing.

Yes and  imho it should be in django by default, not up to end django
users to figure out.
Secure by default please!

>
> Anyway, I would have to agree with Russell, you are simply not making
> yourself clear enough and to added to that seem to keep echoing
> statements that have been refuted.

If you say so. I was pushing some other(more aggressive) impacts in
exotic configurations with custom httpd etc. .


> For the third time I ask you whether you have actually gone and tested
> your hypothesis and can provide a working test case that demonstrates
> the problem.
Ok. Look. You don't use django.
1. Try this - go to the django website
http://docs.djangoproject.com/en/dev/intro/tutorial01/

2. and follow the tutorial 1 (and  also do 2 ) when it says put the
poll file like this:
from django.db import models

class Poll(models.Model):
question = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')

class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice = models.CharField(max_length=200)
votes = models.IntegerField()

put this instead:

from django.db import models
import datetime

class Poll(models.Model):
question = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
filed = models.FileField(upload_to="tmp/")
def __unicode__(self):
return self.question
def was_published_today(self):
return self.pub_date.date() == datetime.date.today()


class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice = models.CharField(max_length=200)
votes = models.IntegerField()
filed = models.FileField(upload_to="tmp/")
def __unicode__(self):
return self.choice

Ok still following?
well you finish the tutorial(s) now and then you try to upload a file right?
So you start uploading the file. Now because (I assume you are still
using the django built in webserver) why don't you play with this a
bit, start uploading say 10 1gb files(all at once) then stop them(all)
at around say 700mb~ in.
Have fun! (obviously you should go further than this and try with
apache setup etc.).

> FWIW, there are much simpler ways to bring a site down than this. I
> suggest you go research Slowloris.
I know about this attack, but I can use my attack against those who
are not using apache.
What do you say to this ?

Here you should get one of these -->
http://www.flickr.com/photos/chrisjrn/4740021871/sizes/l/
Isn't it cute?

--
Small things make base men proud.   -- William Shakespeare, "Henry 
VI"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

On 30 August 2010 11:04, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> On Sun, Aug 29, 2010 at 8:26 PM, dave b <db.pub.m...@gmail.com> wrote:
>  1) An actual problem where you can clearly describe the circumstances
> or sequence of events that would allow an attack to occur, and
>  2) Something that is actually Django's problem -- by which I mean,
> something that is actually Django's responsibility to solve, rather
> than something that is a webserver configuration issue.
>
> At this point, it's not clear to me that either of these two things
> are true. Based on your messages and the feedback from Graham and
> Steve, it sounds like you're describing an attack that *could* exist,
> but only if you've got a misconfigured (or badly implemented) web
> server.
>
> If you believe that I'm wrong, and there *is* an actual problem, you
> need to convince us. This doesn't mean posting large wads of Django's
> source code and proposed patches over multiple messages. It means
> describing in clear, concise language exactly what conditions need to
> exist for a problem to occur.
>
> Yours,
> Russ Magee %-)


Morning. Will do so below here.
Just do remember, there is more than one way to run a httpd, some of
us run our own custom stuff ;) and not everyone is using a setup like
you have.

---

Feature: Attacker crashes your django installation via file uploading
As attacker
I want to crash your django installation
To take your site down or reduce its availability, so I can steal the
underpants and then profit

Background:
Given I am an attacker
And you have uploads enabled with the default settings (memory and
temporary file).
And you are running on a platform with /tmp


Feature: I upload a 1gb file and have this go into system memory
Given I have a 1gb file
When I uploaded it to the website
Then I should see that your system now has used an additional 1gb of /tmp
And available system memory is now reduced


So basically I was saying there are two problems.
One is if the httpd isn't behaving properly(this is probably not
entirely true) with respect to the content length field and abusing
memory limitation.
The second issue is that there is no *default* set limit on temporary
file uploads, so any file larger than 2.5mb can find its way to /tmp
and there is no limit on the size of these files in django core.
That is there is no set limit on the size of a temporary file upload.
The second problem is going to exist within the bounds of the set
limits of the webserver and the various mods that are used with
django.

In an extreme and very unlikely case, the httpd may ungzip the data
from the attacker and modify the content length (when it knows what it
should be - the connection is terminated ) with django getting a large
amount of data to store from a much smaller user body request.


--
Let me take you a button-hole lower.-- William Shakespeare, "Love's
Labour's Lost"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

> Anyway, since you have done your civic duty there's a good chance that a
> fix will find its way into some future version. Thanks for being a good
> citizen.

Django is an awesome project and. However, a bug is a bug. I don't
care if it is a security bug or not, a bug *should* get fixed.

FYI: I sent this information originally to the django security contact
email address as per the website.
This is what I got back.


"I'll be on vacation and offline until December 27th.

I likely won't be responding to the majority of email received between
now and then. If it's important, please re-send the email after the
27th.

Revolution Systems clients should contact  and/or
Frank Wiles at .

In an emergency, I can be contacted at the Ranguana Lodge in
Placencia, Belize. The local number is 523-3112; callers from the US
should call 011-501-523-3112.

Thanks!

Jacob"

So I understand people are busy etc. but ... django is a large project
why did I receive this email?

Required  That's ok all attackers will not look for security
problems in django will not look for bugs while Jacob is away.



--
The ripest fruit falls first.   -- William Shakespeare, "Richard II"

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

> An attacker could also assemble a powerful explosive device and detonate
> it near enough your hosting service to take your site down. What
> counter-measures are you going to take against that?

Good question. I have two cats and they like to lick people ^^
They are a bit friendly I guess. Do you think I can train them to
pounce on strangers?


> You perhaps feel people aren't taking your proposal seriously enough.
> The fact of the matter is that security is never absolute, and on a
> threat scale of 0 to 10 this issue comes in at about 1.7. If you are
> running a professional service and you are monitoring it correctly then
> you ought to notice an attack of this nature before it does too much damage.

Look I send you guys an email, I send a patch for one of the problems
and point out the second one. I just can't make you guys happy can I ?

http://cwe.mitre.org/top25/
[22]145 CWE-770 Allocation of Resources Without Limits or 
Throttling
http://cwe.mitre.org/top25/#CWE-770
But ok if you say so ;)
I wonder how much ram most django commonly found django installations
that allow file upload on the internet have?  now remember a lot of
those have a fairly fast download and upload ;)
bonus points if they have mod_deflate decompressing the user body request ;)

> I repeat, you may be correct in treating this as a vulnerability, but
> your estimate of its seriousness appears to disagree with that of
> others. If you want to have your code seriously considered for inclusion
> (and why not?) you should raise it in the Django issue tracker - see
> "Reporting Bugs" in

I did as I was suggested to do so :)
Some one first told me on irc in #django that I should raise it here first :)

Please see http://code.djangoproject.com/ticket/14192

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

> 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.
>
>

Ok I will do this :-)

Sure Also, Wow gmail is a horrible email client. I am so used to $else.
The patch I included in my previous email should not break any *real*
clients, only evil ones(potentially).

As I understand it an attacker can abuse gzip user requests, if
mod_deflate is enabled (AND configured to decompress incoming user
requests - this is not the default)  in apache2 with a user gziped
request body.

So an attack could do effectively have a file like this:

f = open("rar", "w")
string = ""
for i in range(0, 1000):
string += " " + "1"
f.write(string)
f.close()

ls -lah 20M 2010-08-29 17:15 rar

(except replace write with append and do it a lot more ;) )   and then
send it gziped as in the request body.

Just for fun ;)
gzip rar
ls -lah 19K 2010-08-29 17:15 rar.gz

So  django will receive the original 20M file (as the httpd has
uncompressed it for django ) afaik.

see Input Decompression at http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

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 100
>
> 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.0 
+1000
+++ django/core/files/uploadhandler.py  2010-08-29 14:01:15.0 +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

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

On 29 August 2010 13:17, 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.
>

I meant "no" real protections against this in django core.

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

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.

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

On 28 August 2010 23:21, dave b <db.pub.m...@gmail.com> wrote:
> On 28 August 2010 23:09, dave b <db.pub.m...@gmail.com> wrote:
>> On 28 August 2010 22:46, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
>>>
>>>
>>> On Aug 28, 7:58 pm, "david b." <db.pub.m...@gmail.com> wrote:
>>>> Ok so I was looking through the code and I saw this (in
>>>> django/core/files/uploadhandler.py) :
>>>>
>>>> FileUploadHandler
>>>> ...
>>>>
>>>>    def new_file(self, field_name, file_name, content_type,
>>>> content_length, charset=None):
>>>>        """
>>>>        Signal that a new file has been started.
>>>>
>>>>        Warning: As with any data from the client, you should not trust
>>>>        content_length (and sometimes won't even get it).
>>>>        """
>>>>
>>>> So the content_length we control right? - Maybe I missed something but
>>>> ... I can say I want to upload a small file then upload a file that
>>>> triggers an oom condition / use a lot of memory no ? ...
>>>>
>>>> And then this.
>>>>
>>>> class MemoryFileUploadHandler(FileUploadHandler):
>>>>    """
>>>>    File upload handler to stream uploads into memory (used for small
>>>> files).
>>>>    """
>>>>
>>>>    def handle_raw_input(self, input_data, META, content_length,
>>>> boundary, encoding=None):
>>>>        """
>>>>        Use the content_length to signal whether or not this handler
>>>> should be in use.
>>>>        """
>>>>        # 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:
>>>>            self.activated = False
>>>>        else:
>>>>            self.activated = True
>>>>
>>>>    def new_file(self, *args, **kwargs):
>>>>        super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
>>>>        if self.activated:
>>>>            self.file = StringIO()
>>>>            raise StopFutureHandlers()
>>>>
>>>>    def receive_data_chunk(self, raw_data, start):
>>>>        """
>>>>        Add the data to the StringIO file.
>>>>        """
>>>>        if self.activated:
>>>>            self.file.write(raw_data)
>>>>        else:
>>>>            return raw_data
>>>>
>>>>    def file_complete(self, file_size):
>>>>        """
>>>>        Return a file object if we're activated.
>>>>        """
>>>>        if not self.activated:
>>>>            return
>>>>
>>>>        self.file.seek(0)
>>>>        return InMemoryUploadedFile(
>>>>            file = self.file,
>>>>            field_name = self.field_name,
>>>>            name = self.file_name,
>>>>            content_type = self.content_type,
>>>>            size = file_size,
>>>>
>>>> There is a regression test for this  BUT --> in the test suite there
>>>> is # A small file (under the 5M quota)
>>>> which is governed by
>>>> (django/tests/regressiontests/file_uploads/uploadhandler.py)
>>>>
>>>> def receive_data_chunk(self, raw_data, start):
>>>>        self.total_upload += len(raw_data)
>>>>        if self.total_upload >= self.QUOTA:
>>>>           raise StopUpload(connection_reset=True)
>>>>        return raw_data
>>>>
>>>> So obviously my proposed attack is to simply say "content length is
>>>> tiny" and "this file is actually HUGE".
>>>> I hope I missed something :) I don't really want this to occur ...
>>>
>>> A decent web server such as Apache (under mod_wsgi) will stop reading
>>> the original content at the content length specified in the request.
>>> Thus not possible to force more than content length down to the
>>> application level.
>>>
>>> Graham
>>
>> The documentation and code  in django suggests that this is not the
>> case. So lets assume we are not using apache but another httpd of some
>> sort - then this problem will be present.
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 seems to
>> say otherwise from my reading.
>
> Just to clarify this - I meant that the http content length header
> item is *not* required - as per
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (also see
> 4.4.2), so I do not believe that apache would do what you said :) -
> there is a default limit in a apache of around 2gb for the attackers
> file to reach though.
>

Woop I hit send a bit early, I meant to also include:
So now the attack can now just not specify the content length and um...

>>> None < 2621440
True


We pass the check ;) as far as I know. Look if I really have missed
something do tell me :)

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

On 28 August 2010 23:09, dave b <db.pub.m...@gmail.com> wrote:
> On 28 August 2010 22:46, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
>>
>>
>> On Aug 28, 7:58 pm, "david b." <db.pub.m...@gmail.com> wrote:
>>> Ok so I was looking through the code and I saw this (in
>>> django/core/files/uploadhandler.py) :
>>>
>>> FileUploadHandler
>>> ...
>>>
>>>    def new_file(self, field_name, file_name, content_type,
>>> content_length, charset=None):
>>>        """
>>>        Signal that a new file has been started.
>>>
>>>        Warning: As with any data from the client, you should not trust
>>>        content_length (and sometimes won't even get it).
>>>        """
>>>
>>> So the content_length we control right? - Maybe I missed something but
>>> ... I can say I want to upload a small file then upload a file that
>>> triggers an oom condition / use a lot of memory no ? ...
>>>
>>> And then this.
>>>
>>> class MemoryFileUploadHandler(FileUploadHandler):
>>>    """
>>>    File upload handler to stream uploads into memory (used for small
>>> files).
>>>    """
>>>
>>>    def handle_raw_input(self, input_data, META, content_length,
>>> boundary, encoding=None):
>>>        """
>>>        Use the content_length to signal whether or not this handler
>>> should be in use.
>>>        """
>>>        # 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:
>>>            self.activated = False
>>>        else:
>>>            self.activated = True
>>>
>>>    def new_file(self, *args, **kwargs):
>>>        super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
>>>        if self.activated:
>>>            self.file = StringIO()
>>>            raise StopFutureHandlers()
>>>
>>>    def receive_data_chunk(self, raw_data, start):
>>>        """
>>>        Add the data to the StringIO file.
>>>        """
>>>        if self.activated:
>>>            self.file.write(raw_data)
>>>        else:
>>>            return raw_data
>>>
>>>    def file_complete(self, file_size):
>>>        """
>>>        Return a file object if we're activated.
>>>        """
>>>        if not self.activated:
>>>            return
>>>
>>>        self.file.seek(0)
>>>        return InMemoryUploadedFile(
>>>            file = self.file,
>>>            field_name = self.field_name,
>>>            name = self.file_name,
>>>            content_type = self.content_type,
>>>            size = file_size,
>>>
>>> There is a regression test for this  BUT --> in the test suite there
>>> is # A small file (under the 5M quota)
>>> which is governed by
>>> (django/tests/regressiontests/file_uploads/uploadhandler.py)
>>>
>>> def receive_data_chunk(self, raw_data, start):
>>>        self.total_upload += len(raw_data)
>>>        if self.total_upload >= self.QUOTA:
>>>           raise StopUpload(connection_reset=True)
>>>        return raw_data
>>>
>>> So obviously my proposed attack is to simply say "content length is
>>> tiny" and "this file is actually HUGE".
>>> I hope I missed something :) I don't really want this to occur ...
>>
>> A decent web server such as Apache (under mod_wsgi) will stop reading
>> the original content at the content length specified in the request.
>> Thus not possible to force more than content length down to the
>> application level.
>>
>> Graham
>
> The documentation and code  in django suggests that this is not the
> case. So lets assume we are not using apache but another httpd of some
> sort - then this problem will be present.
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 seems to
> say otherwise from my reading.

Just to clarify this - I meant that the http content length header
item is *not* required - as per
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (also see
4.4.2), so I do not believe that apache would do what you said :) -
there is a default limit in a apache of around 2gb for the attackers
file to reach though.

-- 
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.

Re: potential issue re in memory django file uploading.

[dave b]

On 28 August 2010 22:46, Graham Dumpleton  wrote:
>
>
> On Aug 28, 7:58 pm, "david b."  wrote:
>> Ok so I was looking through the code and I saw this (in
>> django/core/files/uploadhandler.py) :
>>
>> FileUploadHandler
>> ...
>>
>>    def new_file(self, field_name, file_name, content_type,
>> content_length, charset=None):
>>        """
>>        Signal that a new file has been started.
>>
>>        Warning: As with any data from the client, you should not trust
>>        content_length (and sometimes won't even get it).
>>        """
>>
>> So the content_length we control right? - Maybe I missed something but
>> ... I can say I want to upload a small file then upload a file that
>> triggers an oom condition / use a lot of memory no ? ...
>>
>> And then this.
>>
>> class MemoryFileUploadHandler(FileUploadHandler):
>>    """
>>    File upload handler to stream uploads into memory (used for small
>> files).
>>    """
>>
>>    def handle_raw_input(self, input_data, META, content_length,
>> boundary, encoding=None):
>>        """
>>        Use the content_length to signal whether or not this handler
>> should be in use.
>>        """
>>        # 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:
>>            self.activated = False
>>        else:
>>            self.activated = True
>>
>>    def new_file(self, *args, **kwargs):
>>        super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
>>        if self.activated:
>>            self.file = StringIO()
>>            raise StopFutureHandlers()
>>
>>    def receive_data_chunk(self, raw_data, start):
>>        """
>>        Add the data to the StringIO file.
>>        """
>>        if self.activated:
>>            self.file.write(raw_data)
>>        else:
>>            return raw_data
>>
>>    def file_complete(self, file_size):
>>        """
>>        Return a file object if we're activated.
>>        """
>>        if not self.activated:
>>            return
>>
>>        self.file.seek(0)
>>        return InMemoryUploadedFile(
>>            file = self.file,
>>            field_name = self.field_name,
>>            name = self.file_name,
>>            content_type = self.content_type,
>>            size = file_size,
>>
>> There is a regression test for this  BUT --> in the test suite there
>> is # A small file (under the 5M quota)
>> which is governed by
>> (django/tests/regressiontests/file_uploads/uploadhandler.py)
>>
>> def receive_data_chunk(self, raw_data, start):
>>        self.total_upload += len(raw_data)
>>        if self.total_upload >= self.QUOTA:
>>           raise StopUpload(connection_reset=True)
>>        return raw_data
>>
>> So obviously my proposed attack is to simply say "content length is
>> tiny" and "this file is actually HUGE".
>> I hope I missed something :) I don't really want this to occur ...
>
> A decent web server such as Apache (under mod_wsgi) will stop reading
> the original content at the content length specified in the request.
> Thus not possible to force more than content length down to the
> application level.
>
> Graham

The documentation and code  in django suggests that this is not the
case. So lets assume we are not using apache but another httpd of some
sort - then this problem will be present.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 seems to
say otherwise from my reading.

Also as per the django code comment (in django/core/files/uploadhandler.py):

def new_file(self, field_name, file_name, content_type,
content_length, charset=None):
"""
Signal that a new file has been started.

Warning: As with any data from the client, you should not trust
content_length (and sometimes won't even get it).
"""
self.field_name = field_name
self.file_name = file_name
self.content_type = content_type
self.content_length = content_length
self.charset = charset

-- 
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.