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.
