Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

Hi,

Ref Merging Centralized Tokenization.
I found out that some tests for sessions are failing with it. Stupidly,
I didn't have sessions in my test subset for tokenization. Anyway,
I'll try to get it fixed and write some tests for tokens in next few
days.

--
Thanks
Rohan

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!
> 
> Andrew
> 
> On Mon, Aug 20, 2012 at 2:49 PM, Rohan Jain  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 
> > 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 

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

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

Re: GSoC Check-in: Security Enhancements

[Andrew Godwin]

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!

Andrew

On Mon, Aug 20, 2012 at 2:49 PM, Rohan Jain  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 
> 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 

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

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

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

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

Re: GSoC Check-in: Security Enhancements

[Alex Ogier]

On Tue, Jul 24, 2012 at 11:37 PM, Rohan Jain  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.

Best,
Alex Ogier

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

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

On 19:46 +0100 / 23 Jul, Luke Plant wrote:
> On 23/07/12 14:24, Rohan Jain wrote:
> > With this, attacker won't be able to directly set arbitrary tokens on
> > other sub domains through cookies, they will need a signature of the
> > token with the form which is to be verified against the cookie.
> > Plus it also puts a limit on the duration a token stays valid on the
> > server side.
> > 
> > Yes, still with this, someone can spoof the whole pair using a separate
> > legitimate session. So really it doesn't make it completely secure,
> > just makes it little difficult for the attacker.
> 
> So, to make it clear:
> 
> Attacker controls evil.example.com, and wants to attack example.com. By
> appropriate setting of a cookie, and by providing a matching token in
> the form, they can forge a request to example.com
> 
> With your proposed change, they are in no way hampered. Using HMAC to do
> sign the value, and a timestamp, as you mention, they can simply
> regularly directly contact example.com and pull in a valid token/cookie
> value pair, which they can use since there is no correlation to the
> session of the person being attacked. I'm pretty sure this can be done
> entirely in Javascript too.
> 
> Yes, this change would make it "a little difficult". But the value of
> "little" is very small. It's like suggesting we add ROT 13 encryption to
> one of the values - sure it makes it a "little" more difficult, but it
> does not *materially* affect the feasibility of the attack. The
> resources they need are identical: the ability to read the Django source
> code, and the subdomain control that they have in both cases.
> 
> On the other hand, this adds significant complication to our code, which
> is the last thing you need for security related code. I'm -1 on this
> change. I did highlight all these things before.
> 
> 
> > If it weren't for the possibility of attacker injecting cookies from
> > other subdomains, I think CSRF token should be a fine check for
> > CSRF.
> >
> > That is why I am siding on adding referer checking in case of non
> > https scheme requests too.
> 
> I really don't think we can consider this - for HTTP, proxies can and do
> strip the referer header. Quoting from Barth, Jackon and Mitchell:
> 
> <<<
> Over HTTP, sites cannot afford
> to block requests that lack a Referer header because
> they would cease to be compatible with the sizable
> percentage (roughly 3–11%) of users
> >>
> 
> This makes strict referer checking a non-started, and lax referer
> checking (only check it if it is present) has known flaws.

Thanks for this quote. I didn't know about this paper and the fact
that the web behaves differentially with respect to referer checking
in http from https earlier. So, yes relying on it isn't the best idea.

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'
}

Views can have their own custom checkers:

from django.view.decorators.csrf import csrf_checkers

@csrf_checkers(
'django.middleware.csrf.checkers.OriginChecker',
'django.middleware.csrf.checkers.TokenChecker',
)
def foo(request):
'''This view needs token and origin for CSRF checks. For some
reason session can't be used here.'''

@csrf_checkers(
'django.middleware.csrf.checkers.OriginChecker',
'django.middleware.csrf.checkers.SignedTokenChecker',
)
def bar(request):
'''This view for some reason needs time signed token and
origin for CSRF checks.'''


A base checker class:

class BaseCSRFChecker(object):

def __init__(request, *args, **kwargs):
self.request = request

def _accept(self, request):
request.csrf_processing_done = True
return None

def _reject(self, request, reason):
return _get_failure_view()(request, reason=reason)

def _check(strict=True):
raise NotImplementedError ("Checkers must implement a checking 
mechanism.")

def check(strict=True):
# Checkers will implement the method in their 
self._check(strict=strict)

With this I can see some benefits:

 - More explicit about the presence of CSRF checking.
 - Easier to 

Re: GSoC Check-in: Security Enhancements

[Luke Plant]

On 23/07/12 14:24, Rohan Jain wrote:
> With this, attacker won't be able to directly set arbitrary tokens on
> other sub domains through cookies, they will need a signature of the
> token with the form which is to be verified against the cookie.
> Plus it also puts a limit on the duration a token stays valid on the
> server side.
> 
> Yes, still with this, someone can spoof the whole pair using a separate
> legitimate session. So really it doesn't make it completely secure,
> just makes it little difficult for the attacker.

So, to make it clear:

Attacker controls evil.example.com, and wants to attack example.com. By
appropriate setting of a cookie, and by providing a matching token in
the form, they can forge a request to example.com

With your proposed change, they are in no way hampered. Using HMAC to do
sign the value, and a timestamp, as you mention, they can simply
regularly directly contact example.com and pull in a valid token/cookie
value pair, which they can use since there is no correlation to the
session of the person being attacked. I'm pretty sure this can be done
entirely in Javascript too.

Yes, this change would make it "a little difficult". But the value of
"little" is very small. It's like suggesting we add ROT 13 encryption to
one of the values - sure it makes it a "little" more difficult, but it
does not *materially* affect the feasibility of the attack. The
resources they need are identical: the ability to read the Django source
code, and the subdomain control that they have in both cases.

On the other hand, this adds significant complication to our code, which
is the last thing you need for security related code. I'm -1 on this
change. I did highlight all these things before.


> If it weren't for the possibility of attacker injecting cookies from
> other subdomains, I think CSRF token should be a fine check for
> CSRF.
>
> That is why I am siding on adding referer checking in case of non
> https scheme requests too.

I really don't think we can consider this - for HTTP, proxies can and do
strip the referer header. Quoting from Barth, Jackon and Mitchell:

<<<
Over HTTP, sites cannot afford
to block requests that lack a Referer header because
they would cease to be compatible with the sizable
percentage (roughly 3–11%) of users
>>

This makes strict referer checking a non-started, and lax referer
checking (only check it if it is present) has known flaws.

Regards,

Luke

-- 
"Pretension: The downside of being better than everyone else is
that people tend to assume you're pretentious." (despair.com)

Luke Plant || http://lukeplant.me.uk/

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

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

On 11:06 +0100 / 23 Jul, Luke Plant wrote:
> On 23/07/12 08:07, Rohan Jain wrote:
> > ###CSRF Cookies (Time signed):
> > 
> >  - A random token generated by the server stored in the browser cookies. For
> >verification, every non get request will need to provide a signed 
> > version of
> >the same token. This can then be verified on the browser side.
> >  - This can be implemented by adding signing to the existing csrf token 
> > system,
> >using the signing framework.
> >  - A conventional method of CSRF checks, all the major frameworks have 
> > similar
> >systems.
> >  - Signing takes care of the side effects due to cross domain behaviour of
> >cookies.
> >  - Cons:
> > 
> > - Relies on the browser cookies system, which introduces insecurities.
> > - Can be broken easily by having a parallel legitimate session, which 
> > gives
> >   a valid token, signature pair. This generator can then be used in MITM
> >   attacks.
> 
> I don't understand the motivation for this part. Could you describe the
> attack scenarios where this method improves our security with respect to
> the current system?

With this, attacker won't be able to directly set arbitrary tokens on
other sub domains through cookies, they will need a signature of the
token with the form which is to be verified against the cookie.
Plus it also puts a limit on the duration a token stays valid on the
server side.

Yes, still with this, someone can spoof the whole pair using a separate
legitimate session. So really it doesn't make it completely secure,
just makes it little difficult for the attacker.

If it weren't for the possibility of attacker injecting cookies from
other subdomains, I think CSRF token should be a fine check for
CSRF.

That is why I am siding on adding referer checking in case of non
https scheme requests too.

--
Thanks
Rohan

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

Re: GSoC Check-in: Security Enhancements

[Luke Plant]

On 23/07/12 08:07, Rohan Jain wrote:
> ###CSRF Cookies (Time signed):
> 
>  - A random token generated by the server stored in the browser cookies. For
>verification, every non get request will need to provide a signed version 
> of
>the same token. This can then be verified on the browser side.
>  - This can be implemented by adding signing to the existing csrf token 
> system,
>using the signing framework.
>  - A conventional method of CSRF checks, all the major frameworks have similar
>systems.
>  - Signing takes care of the side effects due to cross domain behaviour of
>cookies.
>  - Cons:
> 
> - Relies on the browser cookies system, which introduces insecurities.
> - Can be broken easily by having a parallel legitimate session, which 
> gives
>   a valid token, signature pair. This generator can then be used in MITM
>   attacks.

I don't understand the motivation for this part. Could you describe the
attack scenarios where this method improves our security with respect to
the current system?

Regards,

Luke

-- 
"Pretension: The downside of being better than everyone else is
that people tend to assume you're pretentious." (despair.com)

Luke Plant || http://lukeplant.me.uk/

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

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

Hi,

Centralized Tokenization:
I have merged the work already done for centralized-tokenization in
last djangocon at [yarko/django][0]. Since it there have been 
significant amount of changes since then, merging and resolving
conflicts took a little more time then expected. As of now the tests
are passing. I am yet to do some minor work to move remaining
components to the token system. I'll post it up by tonight or tomorrow
and then document how the system works.

CSRF:
Clubbing the information regarding CSRF, I have started writing down
an overview about it in one place, listing the pros and cons of the
methods for CSRF checking. Its in my same soc proposal gist:

Also added the content of the gist in the end of this mail.


--
Thanks
Rohan

[0]: https://github.com/yarko/django
[1]: https://github.com/crodjer/django/commits/centralized-tokenization

## Current state

Django currently uses two methods for protection against CSRF:

 - In case of http non SSL requests, a conventional token system is used.
 - In case of https requests, we do referer checking.

Both these system introduce a difference in behaviour. Using cookie-token
system provides a side effect feature which lets you access the CSRF token
across multiple subdomains. But the other, referer checking looks for the
request to come from the same host and hence, doesn't allow for cookie like
cross subdomain behaviour.

The fact that there is a `CSRF_COOKIE_DOMAIN` setting shows that django supports
the cross domain capabilities in the CSRF system. So users might utilize this
while building multiple sites. When they change to https scheme, they will see
a new surprising behaviour.

## The modified system
The working tree is at 
[crodjer/django](https://github.com/crodjer/django/tree/csrf-enhancements)
over github.

###Origin and Referer Checking, Permitted domains.

 - Origin header, a fairly new introduction, has CSRF as one of the target.
   Unlike the referer header, it sends back only the domain and the path
   information, so the people don't need to disable these through plugins like
   the referer header.
 - With origin header absent, referer header can be used as a fallback.
 - Strict referer checking is already there in https scheme which is used in all
   major deployments. We can bring it to the non secure scheme also.
 - With this method a permitted domains functionality is possible, which lets
   explicit specification of domains which are trusted and can bypass CSRF. A
   prototype implementation is there at crodjer/django, csrf-enhancements
   branch.

 - Cons:

- Since origin checking is still a new concept, it is not implemented yet in
  major browsers.
- Referer headers spoofing is also heard of in some old versions of flash.
- Plugins which disable referer header are popular. A client which doesn't
  provide origin header and with one such plugin, will fail against this
  kind of checking.

###CSRF Cookies (Time signed):

 - A random token generated by the server stored in the browser cookies. For
   verification, every non get request will need to provide a signed version of
   the same token. This can then be verified on the browser side.
 - This can be implemented by adding signing to the existing csrf token system,
   using the signing framework.
 - A conventional method of CSRF checks, all the major frameworks have similar
   systems.
 - Signing takes care of the side effects due to cross domain behaviour of
   cookies.
 - Cons:

- Relies on the browser cookies system, which introduces insecurities.
- Can be broken easily by having a parallel legitimate session, which gives
  a valid token, signature pair. This generator can then be used in MITM
  attacks.

Given these two methods, I am slightly inclined at Origin/Referer checking,
which is already being completely relied upon in case of the secure requests.

Or we could loose the possibility of permitted domains functionality and
implement both kinds of checks.

On 02:16 +0530 / 10 Jul, Rohan Jain wrote:
> 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 

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

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  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', # 

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

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

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

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

Re: GSoC Check-in: Security Enhancements

[Rohan Jain]

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


On Fri, Apr 27, 2012 at 6:54 PM, Rohan Jain  wrote:
> Hi,
>
> I am Rohan Jain, a student from Indian Institute of Technology,
> Kharagpur. I'll be doing a Google Summer of Code project with django
> this year under the title "Security Enhancements". As the title
> suggests, it has something to do with Security Enhancements: like
> improvements in CSRF protection and tokenization.
>
> I have made some small updates to the proposal with the feedback it
> got. It is under VC over here: http://gist.github.com/2203174
> There isn't a direct way to diff gists, so here are the changes I did
> if somebody has already read the proposal:
>
>  - The origin check will be an additional step to ensure a valid
>   request and not standalone. The conventional checks will still
>   exist.
>
>  - Add some issues Luke pointed out about signing and using sessions.
>
>  - Add info about my github fork and branches.
>
> What I will be doing the following week:
>
>  - I haven't done any major contribution to django yet apart from a
>   tiny ticket some time ago. So, I'll be working on an ticket next
>   few weeks. It is related to filesystem backend of contrib.sessions,
>   was raised some time ago:
>   https://code.djangoproject.com/ticket/18194
>
>  - Cleanup and organize the proposal a bit more (Probably start
>   tracking it as the CSRF protection page -
>   https://code.djangoproject.com/wiki/CsrfProtection)
>
> (I have also appended the current proposal below in this post)
>
> --
> Rohan
>
>
> Proposal
> 
>
> #Abstract
>
> Django is a reasonably secure framework. It provides an API and
> development patterns which transparently take care of the common web
> security issues. But still there are security features which need
> attention. I propose to work and improved CSRF checking without any
> compromises and on integration of existing work on centralized token
> system. If time permits I will also attempt on integration of
> django-secure.
>
> #Description
> ##CSRF Improvements
>
> Cross-Origin Resource Sharing (CORS):
> W3C has a working draft regarding [CORS][w3c-cors-draft], which opens
> up the possibility for allowing client-side request cross-origin
> requests. This directly triggers in mind the capability to develop
> API which can be exposed directly to the web browser. This would let
> us get rid of proxies and other hacks used to achieve this.
> Currently all the major browsers support this: Chrome (all versions),
> Firefox (> 3.0), IE (> 7.0), Safari (> 3.2), Opera (> 12.0). Firefox
> and Chrome send the origin header for both AJAX and standard from POST
> requests. Introduced it here as some further parts of the post refer
> to this.
>
> ###Origin checking
>
> With CORS around need for using CSRF token can be dropped, at least in
> some browsers. [Ticket #16859][orig-check-ticket], is an attempt for
> that. But this was rejected because of neglecting the case for
> presence of `CSRF_COOKE_DOMAIN` (Refer to the closing comment on the
> ticket for details). So to handle this we need to simulate checking of
> CSRF cookie domain as web browsers do it. Maybe:
>
> ```python
>
> reqest.META.get('HTTP_ORIGIN').endswith(settings.CSRF_COOKIE_DOMAIN)
>
> ```
>
> In case the server receives an origin header in the request, it will
> be used for an initial checking and then all the conventional checks
> will be done. The general security will automatically be improved with
> the increased market share of newer browsers which support Origin
> Header.
>
> As the closing comment points it out, we can't do this with secure
> requests. They need to be essentially checked against the referrer or
> origin, at least for now. We can not be sure that some untrusted or
> insecure subdomain has not already set the cookie or cookie domain.
> To deal with this, we have to consider https separately as it is
> being done now. So it will be something like:
>
> ```python
> def process_view(self, request, ):
>
>    # Same initial setup
>
>    if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
>
>        host = request.get_host()
>        origin = 

GSoC Check-in: Security Enhancements

[Rohan Jain]

Hi,

I am Rohan Jain, a student from Indian Institute of Technology,
Kharagpur. I'll be doing a Google Summer of Code project with django
this year under the title "Security Enhancements". As the title
suggests, it has something to do with Security Enhancements: like
improvements in CSRF protection and tokenization.

I have made some small updates to the proposal with the feedback it
got. It is under VC over here: http://gist.github.com/2203174
There isn't a direct way to diff gists, so here are the changes I did
if somebody has already read the proposal:

 - The origin check will be an additional step to ensure a valid
   request and not standalone. The conventional checks will still
   exist.

 - Add some issues Luke pointed out about signing and using sessions.

 - Add info about my github fork and branches.

What I will be doing the following week:

 - I haven't done any major contribution to django yet apart from a
   tiny ticket some time ago. So, I'll be working on an ticket next
   few weeks. It is related to filesystem backend of contrib.sessions,
   was raised some time ago:
   https://code.djangoproject.com/ticket/18194

 - Cleanup and organize the proposal a bit more (Probably start
   tracking it as the CSRF protection page -
   https://code.djangoproject.com/wiki/CsrfProtection)

(I have also appended the current proposal below in this post)

--
Rohan


Proposal


#Abstract

Django is a reasonably secure framework. It provides an API and
development patterns which transparently take care of the common web
security issues. But still there are security features which need
attention. I propose to work and improved CSRF checking without any
compromises and on integration of existing work on centralized token
system. If time permits I will also attempt on integration of
django-secure.

#Description
##CSRF Improvements

Cross-Origin Resource Sharing (CORS):  
W3C has a working draft regarding [CORS][w3c-cors-draft], which opens
up the possibility for allowing client-side request cross-origin
requests. This directly triggers in mind the capability to develop
API which can be exposed directly to the web browser. This would let
us get rid of proxies and other hacks used to achieve this.
Currently all the major browsers support this: Chrome (all versions),
Firefox (> 3.0), IE (> 7.0), Safari (> 3.2), Opera (> 12.0). Firefox
and Chrome send the origin header for both AJAX and standard from POST
requests. Introduced it here as some further parts of the post refer
to this.

###Origin checking

With CORS around need for using CSRF token can be dropped, at least in
some browsers. [Ticket #16859][orig-check-ticket], is an attempt for
that. But this was rejected because of neglecting the case for
presence of `CSRF_COOKE_DOMAIN` (Refer to the closing comment on the
ticket for details). So to handle this we need to simulate checking of
CSRF cookie domain as web browsers do it. Maybe:

```python

reqest.META.get('HTTP_ORIGIN').endswith(settings.CSRF_COOKIE_DOMAIN)

```

In case the server receives an origin header in the request, it will
be used for an initial checking and then all the conventional checks
will be done. The general security will automatically be improved with
the increased market share of newer browsers which support Origin
Header.

As the closing comment points it out, we can't do this with secure
requests. They need to be essentially checked against the referrer or
origin, at least for now. We can not be sure that some untrusted or
insecure subdomain has not already set the cookie or cookie domain.
To deal with this, we have to consider https separately as it is
being done now. So it will be something like:

```python
def process_view(self, request, ):

# Same initial setup

if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):

host = request.get_host()
origin = reqest.META.get('HTTP_ORIGIN', "")
cookie_domain = settings.CSRF_COOKIE_DOMAIN

if request.is_secure():
good_referer = 'https://%s/' % host
referer = origin or request.META.get('HTTP_REFERER')
# Do the same origin checks here

# We are insecure, so care less
# A better way for this check can be used if needed
elif origin.endswith(cookie_domain):
# Safe, continue conventional checking

# Do the conventional checks here
```

If the above were to be implemented, the setting `CSRF_COOKIE_DOMAIN`
should be deprecated for something like `CSRF_ALLOWED_DOMAIN` which
makes more sense.

###Multiple Allowed Domains (was Better CORS Support)
Since, already introducing Origin checking, we can go one step further
and try to provide better support for CORS for browsers supporting it.
A tuple/list setting, which specifies allowed domains will be
provided. Using this the various access control allowance response
headers will be set when the request origin is from amongst the
allowed domains. For CSRF check, just