Hi, This check-in is a little delayed. Meanwhile, I continued working on CSRF and started a on centralized tokenization.
As I had posted, I implemented the permitted domains system, as `CSRF_PERMITTED_DOMAINS`. I did some minor cleanups and tests, the behaviour is mostly the same. Since with the origin header peresent, referer checking can be neglected, now the system bypasses referer checking when origin header is not none. The new permitted domains system is practically invalidated because of the existing csrf cookie and token functionality. So for this, I created a separate branch on my fork, which goes by [purge-cookies][0]. In this I'll try to remove the CSRF cookie functionality without affecting the interface which CSRF checking system provides here. This interface could generate deprecation warnings about CSRF cookie setting and csrf middleware token. Later we can remove this interface completely too. I would also like to get some suggestions if completely shifting towards header checking will be a good idea. From all I could find out from other frameworks out there, tokens and cookies are used to save a state for CSRF checks generally. Header checks are hardly used anywhere. Is it because of some flaw with how the headers system work? Given that referer checking is already being used for request which use the https scheme, I am assuming this is okay to do and will only decrease the vulnerabilites which exists from cookies system. If there are some reasons for using a cookie, we could at least start siging them. Probably have the post form send a signed (and timed?) hash apart from the csrf token for verification. Because otherwise it is easy to break the system if the attacker has access to some other subdomain, maybe on a shared hosting. Awaiting some feedback on CSRF, I have now started looking into integrating a centeralized tokenization system with django. Work for this already exists, done in djangocon 2011 and exists at [yarko/django][1] on github. The commits were on django-old, so it can't be merged directly. I cherry picked commits by commits and ran the merge conflicts with my best guesses. The result of the merge (broken) exists at [centralized-tokenization][2] branch of my fork. I'll have to look into this one more and see if I get it to work, as it does at yarko/django. Also, my first change sets regarding contrib.sessions are still pending some feedback, at [pull-78].[3]. -- Thanks Rohan Jain [0]: https://github.com/crodjer/django/tree/purge-cookies [1]: https://github.com/yarko/django [2]: https://github.com/crodjer/django/commits/centralized-tokenization [3]: https://github.com/django/django/pull/78 On Tue, Jun 12, 2012 at 1:32 PM, Rohan Jain <crod...@gmail.com> wrote: > > I have done some work on CSRF revolving around origin header checking. > The origin header is fairly new and is not yet implemented in a > uniform fashion in the major browsers, so it cannot be solely relied > upon for CSRF checks. Instead we check if the header exists and use it > only for rejection of requests. > > If an `HTTP_ORIGIN` header is sent by the browser, it checks if it > matches to be from a valid origin. In case it is not the request is > rejected right away. Otherwise it proceeds for further CSRF checks > > Because of the way browser cookies behave, I had to do some unpleasant > tweaks to origin header checking such that `COOKIE_DOMAIN_SETTING` is > followed. From the commit: > > if not ((good_origin.startswith('.') > and good_origin.count('.') is origin.count('.') > and origin.endswith(good_origin)) > or origin[origin.find('://')+3:] == good_origin): > > All this is because using cookies open the possibility for allowing > cross subdomain requests (a side effect?). I had a chat with Paul for > breaking (fixing) this behaviour. The plan is to: > > - Make the strict referer checking, currently implemented only for > HTTPS, default for http requests too. The http scheme which is more > popular definitely deserves better checking. > - Make the origin checking work similar to the way referer checking > is done. Also, will it be safe to bypass referer checking in case > of origin header being present? > - Implement a PERMITTTED_DOMAINS setting which lets administrators > explicitly mention the domains which are permitted to make the > otherwise restricted requests. This gives more control to the > administrators. > - The PERMITTED_DOMAINS setting, a list, accepts patterns. Regex > cannot be used here because characters like `.`, `-` will need > escaping. So I decided to settle on the simpler unix style globs. > The pattern matching is done through the `fnmatch` library > function, documented [here][fnmatch-docs]. One can use this setting > like this: > > PERMITTED_DOMAINS = [ > 'www.example.com', # Exactly the domain `www.example.com` > '*.supertrusteddomain.com', # All subdomains to > `supertrusteddomain.com` > '?.services.example.com', # Single letter subdomains to > `.services.example.com` > ] > > I have done an initial implementation of these, changes in [pull > request #95][pull-95]. I'll now proceed to clean these up, writing > better tests and documentation for these. Also with these, we can > completely get rid of the cookie based CSRF check system. > > -- > Thanks > Rohan Jain > > [fnmatch-docs]: http://docs.python.org/library/fnmatch.html > [pull-95]: https://github.com/django/django/pull/95 > > On 20:10 +0530 / 21 May, Rohan Jain wrote: > > Hi, > > > > Since my last check in I worked on improvements to > > contrib.sessions: > > > > - Introduction of signing framework > > - Session expiry checks (for Ticket [#18194][0] > > - And some other trivial patches. > > > > The tests (existing and the one which I added) are passing. > > > > These changes are in my [Pull Request #78][1] over github. > > Paul, could you please review it to see if the patches are usable. > > > > Next, I'll make the changes which may be required in documentation > > because of the above. > > Today is official start date of the GSoC project, so I'll now start > > concentrating more on the project now. > > > > Rohan Jain > > > > [0]: https://code.djangoproject.com/ticket/18194 > > [1]: https://github.com/django/django/pull/78 > > > > On Mon, May 7, 2012 at 12:21 PM, Rohan Jain <crod...@gmail.com> wrote: > > > Hi, > > > > > > Last week I looked into the Ticket [#18194][0]: > > > > > > - Trivial attempts to handle the issue. > > > - Wrote a minor initial patch. > > > - The test fails for Cache and Cookie backend. > > > > > > Also, I looked at the talks from Paul regarding advanced security > > > topics at py/django cons. Realised that why I should not attempt > > > anything related to encryption in my project. > > > > > > There is high academic pressure currently, so I am not able to give > > > enough time to these. I think the situation will be better this > > > weekend onwards. > > > > > > I'll try to work on: > > > > > > - Write tests which emulate the problem in #18194 well, and then work > > > on the final fix. > > > - Start looking into resources useful for my project, like [The > > > Tangled Web][1]. > > > > > > Rohan Jain > > > > > > > > > [0]: https://code.djangoproject.com/ticket/18194 > > > [1]: > > > http://www.amazon.com/The-Tangled-Web-Securing-Applications/dp/1593273886 -- 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.
