Hi,

Thanks for the reply.

On 10:50 +0100 / 21 Aug, Andrew Godwin wrote:
> Thanks for your work during the GSOC, Rohan - don't worry about not
> achieving everything, it looks like there's still some useful code there!
> 
> Hopefully we can get some of the code merged, especially centralised
> tokenisation if it's so near completion, as it looks like a nice bit of
> cleanup code!

Hoping that we can merge and ship it by 1.5. There is a possibility of
running into issues still, I'll try to fix those as they come up in
future.

--
Rohan

> 
> Andrew
> 
> On Mon, Aug 20, 2012 at 2:49 PM, Rohan Jain <crod...@gmail.com> wrote:
> 
> > Hi,
> >
> > Today is the 'pencils down' date for this GSoC project. Past 4 months
> > have been a great learning experience from me. Just being in the
> > context of security side of the web has been really beneficial. Moving
> > around in a very well written code base is also delightful.
> > Meanwhile, I did get to work on multiple sections of the code base.
> > But compared to the expectations at the initial phase of the program,
> > I myself am a little disappointed about the output I was able to
> > generate out of the time - specially regarding CSRF.
> > This can be attributed to my being unable to give consistent attention
> > to the project through the duration and to solicit feedback. Also, the
> > project comprised of multiple discreet tasks, so not enough
> > consideration was there for each task.
> >
> > This is a overview of various complete/incomplete topics I worked on.
> >
> > Centralized Tokenization:
> > This was about integrating a central tokenization api throughout the
> > django project. I tracked this at [centralized-tokenization][0] branch
> > of my fork on github. This is near completion, and also has a
> > documentation[1] of the API with basic usage examples.
> >
> > Improvements to sessions:
> > My first task, related to some improvements to the sessions framework.
> > Includes signing and session cleanup based on the engine. Tracked at
> > [sessions-improvements][2] branch.
> >
> > CSRF Enhancements:
> > It occupied most of my time through the project. I tried multiple ways
> > to solve the issues under this. Tracked at [csrf-enhancements][3].
> > First up, I started with using the origin header for doing a CSRF
> > check. One implementation with some tests is at
> > [csrf-origin-checking][4]. Recently I started on the idea of
> > implementing moduler checkers for each kind of CSRF check, but
> > haven't got anything useful out of it yet. While progressing, it
> > seemed like I was virtually writing a middleware per checker, so now I
> > have moved on to attempt on CSRF cookie store. Basically something
> > which should seamlessly switch Session/Cookie for storage based on the
> > availability of session.
> >
> > I'll try to hang around the django bug tracker and submit some
> > patches.
> >
> > --
> > Thanks
> > Rohan Jain
> >
> > [0]: https://github.com/crodjer/django/tree/centralized-tokenization
> > [1]:
> > https://github.com/crodjer/django/blob/centralized-tokenization/docs/topics/tokenization.txt
> > [2]: https://github.com/crodjer/django/tree/sessions-improvements
> > [3]: https://github.com/crodjer/django/tree/csrf-enhancements
> > [4]: https://github.com/crodjer/django/tree/csrf-origin-checking
> > [5]: https://github.com/crodjer/django/tree/csrf-moduler-checkers
> >
> > On 01:57 +0530 /  7 Aug, Rohan Jain wrote:
> > > 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.
> >
> >
> 
> -- 
> 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.
> 

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

Reply via email to