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: OT: security announcements for Django-related libraries

[Luke Plant]

Hi Adam,

To avoid fragmenting the discussion, could you reply on the thread I
linked to on Python Security?

Thanks,

Luke

On 23/07/12 13:36, Adam "Cezar" Jenkins wrote:
> Now. I'm going to preface this with being that I am totally nieve about
> such things. Wouldn't it be nice if you could mark a release on PyPI as
> a security release and Pip could just do security updates? Somewhat like
> a few Linux distributions do.
> 
> Of course that's a long term goal. A mailing list is almost a given. For
> my needs, something with and RSS feed would be great.
> 
> On Mon, Jul 23, 2012 at 5:55 AM, Luke Plant  > wrote:
> 
> Hi all,
> 
> I started a thread on the 'Python security' list about the need for a
> place for 3rd party Django/Python libraries to announce security issues,
> for the very common case of small libraries that wouldn't even have
> their own mailing list - or would have a fraction of their user base
> subscribed to the mailing list - but could have real security
> vulnerabilities.
> 
> At the moment I'm suggesting a single purpose mailing list that Python
> web developers could be subscribed to.
> 
> The thread is here:
> https://groups.google.com/d/topic/python-security/NmHU_VA4V6I/discussion
> 
> The group is moderated, so I've got a couple of replies that haven't
> shown up yet.
> 
> 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.
> 
> 
> -- 
> 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.


-- 
"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: OT: security announcements for Django-related libraries

[Adam "Cezar" Jenkins]

Now. I'm going to preface this with being that I am totally nieve about
such things. Wouldn't it be nice if you could mark a release on PyPI as a
security release and Pip could just do security updates? Somewhat like a
few Linux distributions do.

Of course that's a long term goal. A mailing list is almost a given. For my
needs, something with and RSS feed would be great.

On Mon, Jul 23, 2012 at 5:55 AM, Luke Plant  wrote:

> Hi all,
>
> I started a thread on the 'Python security' list about the need for a
> place for 3rd party Django/Python libraries to announce security issues,
> for the very common case of small libraries that wouldn't even have
> their own mailing list - or would have a fraction of their user base
> subscribed to the mailing list - but could have real security
> vulnerabilities.
>
> At the moment I'm suggesting a single purpose mailing list that Python
> web developers could be subscribed to.
>
> The thread is here:
> https://groups.google.com/d/topic/python-security/NmHU_VA4V6I/discussion
>
> The group is moderated, so I've got a couple of replies that haven't
> shown up yet.
>
> 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.
>
>

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

OT: security announcements for Django-related libraries

[Luke Plant]

Hi all,

I started a thread on the 'Python security' list about the need for a
place for 3rd party Django/Python libraries to announce security issues,
for the very common case of small libraries that wouldn't even have
their own mailing list - or would have a fraction of their user base
subscribed to the mailing list - but could have real security
vulnerabilities.

At the moment I'm suggesting a single purpose mailing list that Python
web developers could be subscribed to.

The thread is here:
https://groups.google.com/d/topic/python-security/NmHU_VA4V6I/discussion

The group is moderated, so I've got a couple of replies that haven't
shown up yet.

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

[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