Hi,
Sorry for the delay in getting back. I was meanwhile working on
centralized tokenization for few days, while still trying to figure
something better for CSRF.
On 03:52 -0400 / 25 Jul, Alex Ogier wrote:
> On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain <crod...@gmail.com> wrote:
> >
> > I had one more idea, "Pluggable CSRF checkers".
> >
> > Currently, the CSRF middleware has two kinds of checks, referer (for
> > https) and secret validation token (common). These with origin header
> > based checker (if we add it) come in conditional blocks, making
> > switching them difficult. So what I propose to do is decouple their
> > logic from CSRF middleware and each of them provide a checker. It goes
> > like this:
> >
> > A setting for configuring global CSRF checkers:
> >
> > CSRF_CHECKERS = {
> > 'django.middleware.csrf.checkers.OriginChecker',
> > # This one can be strict for https and lax for http
> > 'django.middleware.csrf.checkers.RefererChecker',
> > # contrib.sessions could provide a csrf checker maintained
> > # with sessions. This stores the token in session data.
> > 'django.contrib.sessions.csrf_checkers.SessionChecker'
> > }
> >
>
> I don't think this is a good idea. If you enumerate security features
> in settings.py, then later additions won't be picked up by default. If
> Django add a new CSRF checking mechanism, we want everybody to take
> advantage of it with no modifications.
>
> Ordinarily I agree with you, explicit is better than implicit.
> However, in the case of security features, I think this is inverted:
> Django sites should be implicitly enrolled in all security mechanisms
> if possible, and should be able to explicitly opt out if necessary.
> Almost everyone should be using every single protection Django offers
> on all their requests, and therefore it should be verbose and
> discouraged to turn off these protections.
>
Hmm, that is a valid point. I can drop the configurable CSRF settings.
But still a modular CSRF checkers might be useful, in which the
checkers are selected dynamically. When sessions app is present, use
sessions checker instead of cookies based CSRF token store. Also we
can have switches which incorporate existing behaviour based on
https/http connection and also origin header checking based on its
presence. I will do a prototype implementation for this to polish and
clarify the idea.
## Centralized Tokenization:
A functioning implementation is up at the [centralize-tokenization][0]
branch on my fork. I have written an [initial documentation][1] for
this too. This is basically a merge with my cleanups and
customizations over the work done in period of [djangocon 2011][2].
[0]: https://github.com/crodjer/django/commits/centralized-tokenization
[1]: https://gist.github.com/2203174#file_tokenization.mkd
[2]: https://github.com/yarko/django/commits/djangocon2011-sec
--
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.
