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.