Re: GSoC 2012: Security Enhancements

[Rohan Jain]

On 22:50 +0100 / 13 Apr, Luke Plant wrote:
> Hi Rohan,
> 
> Sorry for the slow reply on this one, I've had a busy time recently.
> Please see my comments on some parts of this proposal.

No worries about this.
> 
> On 31/03/12 19:10, Rohan Jain wrote:
> > Hi,
> > 
> > I am Rohan Jain, a 4th (final) year B.Tech undergraduate Student from
> > Indian Institute of Technology, Kharagpur. I have been using django
> > since over a year and generally look into the code base to find about
> > various implementations. I have made attempts to make some minor 
> > contributions and if selected this would be my first major one.
> > 
> > More about Me:  IRC, Github: crodjer
> > 
> > I am interested in contributing some security enhancements to django 
> > as my Summer of Code project. Below is the 1st draft of my proposal 
> > regarding this. A pretty version of this is available at: 
> > https://gist.github.com/2203174
> > 
> > 
> > #Abstract
> > 
> > Django is a reasonably secure framework. It provides an API and 
> > development patterns which transparently take care of the common web 
> > security issues. But still there are security features which need 
> > attention. I propose to work on integration of existing work on 
> > centralized token system and improved CSRF checking without any 
> > compromises. If time permits I will also attempt on integration of 
> > django-secure.
> > 
> > #Description ##Centralized tokenization There are multiple places in
> > django which use some or other kinds of tokens:
> > 
> > - contirb.auth (random password, password reset) - formtools -
> > session (backends) - cache - csrf - etags
> > 
> > Token generation is pretty common around the framework.  So, instead 
> > of each application having its own token system, and hence needs to
> > be maintained separately. There should be centralized token system,
> > which provides an abstract API for everyone to loose. In fact, I have
> > seen that some apps use `User.objects.make_random_password` from 
> > contrib.auth, which they can be sure of being maintained in the
> > future for random generation. To me this looks kind of weird. In last
> > djangocon, a lot of work regarding this was done over [Yarko's 
> > Fork][yarko-fork].
> > 
> > I had a discussion with Yarko Tymciurak regarding this. The work is 
> > nearly ready for a merge, only some tasks left. In the initial
> > period my SoC I can work over these to insure that the already done 
> > significant work gets in django and is updated for 1.5.
> > 
> > - Porting more stuff to the new system (README.sec in [yarko's
> > fork][yarko-fork]) - Testing - See if the current coverage of the
> > tests is enough, write them if not. - Compatibility issues - API
> > Documentation
> > 
> > I will study the changes done at djangocon and then attempt the
> > tasks mentioned above.
> > 
> > ##CSRF Improvements
> > 
> > Cross-Origin Resource Sharing (CORS): W3C has a working draft
> > regarding [CORS][w3c-cors-draft], which opens up the possibility for
> > allowing client-side request cross-origin requests. This directly
> > triggers in mind the capability to develop API which can be exposed
> > directly to the web browser. This would let us get rid of proxies and
> > other hacks used to achieve this. Currently all the major browsers
> > support this: Chrome (all versions), Firefox (> 3.0), IE (> 7.0),
> > Safari (> 3.2), Opera (> 12.0). Introduced it here as some further
> > parts of the post refer to this.
> > 
> > ###Origin checking
> > 
> > With CORS around need for using CSRF token can be dropped, at least
> > in some browsers. [Ticket #16859][orig-check-ticket], is an attempt
> > for that. But this was rejected because of neglecting the case for 
> > presence of `CSRF_COOKE_DOMAIN` (Refer to the closing comment on the 
> > ticket for details). So to handle this we need to simulate checking
> > of CSRF cookie domain as web browsers do it. Maybe:
> > 
> > ```python 
> > reqest.META.get('HTTP_ORIGIN').endswith(settings.CSRF_COOKIE_DOMAIN) 
> > ```
> 
> I'm very cautious about making the logic here more complex. It can be
> done, but every additional code path increases the possibility of a
> security hole. ..

Yes, this will touch critical code of the framework and cannot afford
to expose any possible vulnerabilities. That is why I am planning of a
thorough security level testing and of course any patch relating this
(or anything else in this security related proposal) will need careful
reviews before being considered safe.

> .. At the moment, it seems that few browsers send the
> 'Origin' header for normal HTML requests. (Recent versions of Chrome,
> Firefox and Opera do not, I don't know about IE).

Page, http://caniuse.com/cors mentions the browsers and their versions
which support CORS. A big share of browser does support it and another
big one (constituting old IE and Opera) does not. We cannot expect
these browsers to go away anytime soon, so we have 

Re: QuerySet filtering weirdness for dates with 3-digit years

[Andy McKay]

>From my brief reading of the some docs (eg postgresql) it looks like
dates with less than 4 years do need to be prefixed with a zero, in
the standard date format (some databases let you set different
formats). But since python doesn't output a 0, I can see why its going
wrong:

>>> datetime(999,1,1,1).year
999

Interestingly sqlite uses standard strftime
http://www.sqlite.org/lang_datefunc.html:

%Y  year: -

I thought the answer might be to use strftime but:

>>> datetime(999,1,1,1).strftime('%Y')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: year=999 is before 1900; the datetime strftime() methods
require year >= 1900

Which is this bug: http://bugs.python.org/issue1777412

This isn't a problem that I can imagine many people have run into, so
sounds like a bug needing a patch. Good luck!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

QuerySet filtering weirdness for dates with 3-digit years

[Evan Carmi]

Hi all,

I'm leading a small group of CS majors in a software development forum 
focused on learning (and hopefully contributing to) Django at Wesleyan 
University.

While getting started with the Django Tutorial we noticed some odd behavior 
that seems to be a bug. If the case, we'd love to be the ones to help out 
and create a patch.

The issue is the following: Filtering using the QuerySet API seems to build 
incorrect SQL statements for early dates such as year 1.

An example from the Django Tutorial:

from polls.models import Polls
import datetime
>>> q = Poll(question="What's up?", pub_date=datetime.datetime.now())
>>> p = Poll(question="Will this work?", 
pub_date=datetime.datetime(1,1,1,1,1))

>>> p.save()
>>> q.save()

>>> Poll.objects.filter(pub_date__year=2012) # We should get the poll q 
(and we do)
[]

>>> Poll.objects.filter(pub_date__year=1) #We should get the poll p (but we 
don't)
[]

This seems to be the case for all dates with a non 4 digit year (999, also 
has some problem).

The SQL queries that are being generated are (for sqlite):

{'sql': u'INSERT INTO "polls_poll" ("question", "pub_date") VALUES (Year is 
999, 0999-09-09 00 <+33999090900>:00:00)',
 'time': '0.043'},
{'sql': u'SELECT "polls_poll"."id", "polls_poll"."question", 
"polls_poll"."pub_date" FROM "polls_poll" WHERE "polls_poll"."pub_date" 
BETWEEN 999-01-01 and 999-12-31 23:59:59.99 LIMIT 21',
 'time': '0.000'}]

So it seems like there is a normalization process of converting all years 
into a 4 digit integer when creating objects, but when searching or 
filtering for objects the years the SQL isn't correct. I'd think the 
correct SQL statement should simply have the year dates have 4 digits like 
the SQL statement which works:

sqlite> SELECT "polls_poll"."id", "polls_poll"."question", 
"polls_poll"."pub_date" FROM "polls_poll" WHERE "polls_poll"."pub_date" 
BETWEEN "0999-01-01" and "0999-12-31 23 <+33999123123>:59:59.99";
5|Year is 999|0999-09-09 00 <+33999090900>:00:00

If this is, in fact, a bug and not intentional we'd love to be the ones to 
create tests and a patch.

Cheers,
Evan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/I95Mmv38wyUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.