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 <[email protected]> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
