Re: csrf cookie security

[Russell Keith-Magee]

On Fri, Feb 11, 2011 at 1:07 AM, Daniel Roseman  wrote:
> On Thursday, February 10, 2011 4:48:05 PM UTC, Brian Craft wrote:
>>
>> I'll have to look at this in more detail, but two notes, off-the-top.
>>
>> First, port 80 is kept open because the browser will try port 80 if
>> the user types in the url without the protocol. On port 80 all we do
>> is issue a redirect to https, but the client will have spilled the
>> cookies by then.
>>
>> Second, the most like scenario for this to happen is with a wireless
>> MITM. E.g. an attacker sits in, or near a coffee shop, or office, with
>> a laptop setup as an AP, trolling for connections from unsuspecting
>> users. If anyone connects, the laptop can be used as a MITM. So, for
>> example, when the user types the url and hits port 80, the MITM can
>> create an https connection to the target site, and return it via http.
>>
>> I'm not certain there's a csrf attack here, but I suspect there is.
>
> Just a warning: if you think you're getting close to identifying a security
> hole, please don't post it in a public newsgroup, but email it directly to
> the private Django security list: secur...@djangoproject.com

Firstly, *YES PLEASE OH PLEASE YES*. If you even *suspect* that you
have a found security hole, please don't discuss it in a public forum
-- contact secur...@djangoproject.com.

Secondly, please search the list archives for discussions of MITM
attacks, and the discussion of MITM on the CSRF design page [1]. There
are known limitations with CSRF protection in general, and Luke Plant
has done a great job elaborating on them in the past.

[1] http://code.djangoproject.com/wiki/CsrfProtection

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: csrf cookie security

[Daniel Roseman]

On Thursday, February 10, 2011 4:48:05 PM UTC, Brian Craft wrote:
>
> I'll have to look at this in more detail, but two notes, off-the-top.
>
> First, port 80 is kept open because the browser will try port 80 if
> the user types in the url without the protocol. On port 80 all we do
> is issue a redirect to https, but the client will have spilled the
> cookies by then.
>
> Second, the most like scenario for this to happen is with a wireless
> MITM. E.g. an attacker sits in, or near a coffee shop, or office, with
> a laptop setup as an AP, trolling for connections from unsuspecting
> users. If anyone connects, the laptop can be used as a MITM. So, for
> example, when the user types the url and hits port 80, the MITM can
> create an https connection to the target site, and return it via http.
>
> I'm not certain there's a csrf attack here, but I suspect there is.
>
Just a warning: if you think you're getting close to identifying a security 
hole, please don't post it in a public newsgroup, but email it directly to 
the private Django security list: secur...@djangoproject.com
--
DR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: csrf cookie security

[Brian Craft]

I'll have to look at this in more detail, but two notes, off-the-top.

First, port 80 is kept open because the browser will try port 80 if
the user types in the url without the protocol. On port 80 all we do
is issue a redirect to https, but the client will have spilled the
cookies by then.

Second, the most like scenario for this to happen is with a wireless
MITM. E.g. an attacker sits in, or near a coffee shop, or office, with
a laptop setup as an AP, trolling for connections from unsuspecting
users. If anyone connects, the laptop can be used as a MITM. So, for
example, when the user types the url and hits port 80, the MITM can
create an https connection to the target site, and return it via http.

I'm not certain there's a csrf attack here, but I suspect there is.


On Wed, Feb 9, 2011 at 11:28 PM, Ian Clelland  wrote:
> On Wed, Feb 9, 2011 at 11:51 AM, Brian Craft  wrote:
>> I thought, rather, that the csrf token was a cookie that was put in a
>> hidden form field.
>
> You're absolutely right; I wasn't thinking about that side of the token.
>
>> With firebug or webkit dev tools you can see the django csrf token in
>> the cookies. I would also refer you to middleware/csrf.py, where you
>> can see it doing the set_cookie.
>>
>> I thought the security of the csrf token relied on the fact that the
>> 3rd party wouldn't know what value to put in the hidden form field.
>> The csrf middleware is, I believe, validating the value in the form
>> field, against the value in cookie. But when it creates the form, it
>> uses the value in the cookie.
>>
>> If the token is stored in an insecure cookie, it can be sniffed. Then
>> I don't understand what prevents the attacker from constructing a
>> valid form.
>
> If you want a secure cookie, that means that your entire site (or at
> least the form-handling bits) must already be protected by SSL (since
> a secure cookie will only be returned over an SSL connection).
>
> The threat model you are proposing, then, sounds like this: There is a
> website, running Django, using Django's CSRF protection, in which all
> of the form-handling views are only accessible over HTTPS, but there
> are other resources in the same domain (or its subdomains) which are
> accessible over HTTP.
>
> Further, there is an attacker, who can sniff the unencrypted HTTP
> traffic, and can construct an HTML page at a different site (this is
> Cross-Site Request Forgery, after all)
>
> A lot of the potential damage seems to be mitigated by another check
> in django/middleware/csrf.py, for HTTPS requests only, that inpects
> the referer header of the incoming request, to ensure that the browser
> was not submitting the form from a different site. To get around that,
> the attacker would have to be able to construct a form on the
> SSL-protected site (a serious html-injection vulnerability would have
> to be present), or cause the request to be submitted over plain HTTP
> -- but the site is already HTTPS-only, so there shouldn't be any
> form-handling code listening on that port.
>
> Does this threat model correspond to what you're thinking? If so, I
> don't see away around the CSRF protection (at least, not one that
> involves the victim's browser)
>
>
> --
> Regards,
> Ian Clelland
> 
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: csrf cookie security

[Ian Clelland]

On Thu, Feb 10, 2011 at 5:21 AM, Lior Sion  wrote:
> It's been a while since I dealt with those things, but what about this
> scenario:
>
> The attacker detects the CSRF code using an attack resembling the
> scenario here:
>
> http://wiki.developerforce.com/index.php/Secure_Coding_Secure_Communications#Secure_Communications_and_Cookies
>
> [to save some time, this is the quote:
>
> Failure to set the Secure flag for security-critical cookies is the
> most common vulnerability in this category. Simply setting a cookie
> over an HTTPS connection does not prevent it from being returned over
> HTTP unless the Secure flag is set. Even if your site does not have an
> HTTP version, malicious parties on the network may be able to steal
> session cookies.
>
> There are several ways to achieve this. For example, the attacker may
> insert references to HTTP URLs to your application into sites that
> your users are likely to visit. Assume your application is 
> https://app.example.com,
> and your users frequent a discussion forum/blog at http://exampleappblog.com.
> ExampleAppBlog allows commenters to include limited HTML in their
> posts, including img tags. A commenter inserts HTML into one of their
> comments like the following:
>
> http://app.example.com/example-logo.png;
> class="external free" title="http://app.example.com/example-logo.png;
> rel="nofollow">http://app.example.com/example-logo.png" />
> When a user authenticated to app.example.com views this comment, their
> browser will fire off a request for example-logo.png over an insecure
> HTTP connection. Since the app.example.com cookie was not set Secure,
> the browser will include the cookie over this connection — exposing it
> to the network.
>
> ]
>
> Once they have the CSRF cookie, they use the site itself (example.com)
> and post malicious code there with the right CSRF.
>
> I agree it's not an easy attack, but why not turning on the secured
> flag for cookies on https?

This is a general attack against cookies; certainly, if an attacker
can steal all of your cookies, and can interfere with your network
connection, he can do a lot, with or without CSRF protection.

More specifically, the attack you present is more relevant to the
session cookie than the the CSRF-token cookie. If an attacker can
sniff your connection, and retrieve the cookies from it, then why not
just grab your session cookie (it's no more or less secure than the
CSRF cookie), and use it to impersonate you on the site? He won't even
need the CSRF token; he can just use any GET request to a page with a
form on it to get a new one.

If you are worried about an attacker who can sniff your network, you
have more to worry about than the 'secure' flag on your CSRF cookies.
You need to make sure that your login credentials (username/password)
are never sent in the clear, that your session cookie is never sent in
the clear, and that essentially your whole site is protected by SSL,
such that a request coming in over plain HTTP, even if properly
authenticated, is still rejected. Once you have this in place, the
secure flag on the CSRF cookie becomes irrelevant. An attacker can't
do any more damage with it than he could by any other means.

-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: csrf cookie security

[Lior Sion]

It's been a while since I dealt with those things, but what about this
scenario:

The attacker detects the CSRF code using an attack resembling the
scenario here:

http://wiki.developerforce.com/index.php/Secure_Coding_Secure_Communications#Secure_Communications_and_Cookies

[to save some time, this is the quote:

Failure to set the Secure flag for security-critical cookies is the
most common vulnerability in this category. Simply setting a cookie
over an HTTPS connection does not prevent it from being returned over
HTTP unless the Secure flag is set. Even if your site does not have an
HTTP version, malicious parties on the network may be able to steal
session cookies.

There are several ways to achieve this. For example, the attacker may
insert references to HTTP URLs to your application into sites that
your users are likely to visit. Assume your application is 
https://app.example.com,
and your users frequent a discussion forum/blog at http://exampleappblog.com.
ExampleAppBlog allows commenters to include limited HTML in their
posts, including img tags. A commenter inserts HTML into one of their
comments like the following:

http://app.example.com/example-logo.png;
class="external free" title="http://app.example.com/example-logo.png;
rel="nofollow">http://app.example.com/example-logo.png" />
When a user authenticated to app.example.com views this comment, their
browser will fire off a request for example-logo.png over an insecure
HTTP connection. Since the app.example.com cookie was not set Secure,
the browser will include the cookie over this connection — exposing it
to the network.

]

Once they have the CSRF cookie, they use the site itself (example.com)
and post malicious code there with the right CSRF.

I agree it's not an easy attack, but why not turning on the secured
flag for cookies on https?




On Feb 10, 9:28 am, Ian Clelland  wrote:
> On Wed, Feb 9, 2011 at 11:51 AM, Brian Craft  wrote:
> > I thought, rather, that the csrf token was a cookie that was put in a
> > hidden form field.
>
> You're absolutely right; I wasn't thinking about that side of the token.
>
> > With firebug or webkit dev tools you can see the django csrf token in
> > the cookies. I would also refer you to middleware/csrf.py, where you
> > can see it doing the set_cookie.
>
> > I thought the security of the csrf token relied on the fact that the
> > 3rd party wouldn't know what value to put in the hidden form field.
> > The csrf middleware is, I believe, validating the value in the form
> > field, against the value in cookie. But when it creates the form, it
> > uses the value in the cookie.
>
> > If the token is stored in an insecure cookie, it can be sniffed. Then
> > I don't understand what prevents the attacker from constructing a
> > valid form.
>
> If you want a secure cookie, that means that your entire site (or at
> least the form-handling bits) must already be protected by SSL (since
> a secure cookie will only be returned over an SSL connection).
>
> The threat model you are proposing, then, sounds like this: There is a
> website, running Django, using Django's CSRF protection, in which all
> of the form-handling views are only accessible over HTTPS, but there
> are other resources in the same domain (or its subdomains) which are
> accessible over HTTP.
>
> Further, there is an attacker, who can sniff the unencrypted HTTP
> traffic, and can construct an HTML page at a different site (this is
> Cross-Site Request Forgery, after all)
>
> A lot of the potential damage seems to be mitigated by another check
> in django/middleware/csrf.py, for HTTPS requests only, that inpects
> the referer header of the incoming request, to ensure that the browser
> was not submitting the form from a different site. To get around that,
> the attacker would have to be able to construct a form on the
> SSL-protected site (a serious html-injection vulnerability would have
> to be present), or cause the request to be submitted over plain HTTP
> -- but the site is already HTTPS-only, so there shouldn't be any
> form-handling code listening on that port.
>
> Does this threat model correspond to what you're thinking? If so, I
> don't see away around the CSRF protection (at least, not one that
> involves the victim's browser)
>
> --
> Regards,
> Ian Clelland
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: csrf cookie security

[Ian Clelland]

On Wed, Feb 9, 2011 at 11:51 AM, Brian Craft  wrote:
> I thought, rather, that the csrf token was a cookie that was put in a
> hidden form field.

You're absolutely right; I wasn't thinking about that side of the token.

> With firebug or webkit dev tools you can see the django csrf token in
> the cookies. I would also refer you to middleware/csrf.py, where you
> can see it doing the set_cookie.
>
> I thought the security of the csrf token relied on the fact that the
> 3rd party wouldn't know what value to put in the hidden form field.
> The csrf middleware is, I believe, validating the value in the form
> field, against the value in cookie. But when it creates the form, it
> uses the value in the cookie.
>
> If the token is stored in an insecure cookie, it can be sniffed. Then
> I don't understand what prevents the attacker from constructing a
> valid form.

If you want a secure cookie, that means that your entire site (or at
least the form-handling bits) must already be protected by SSL (since
a secure cookie will only be returned over an SSL connection).

The threat model you are proposing, then, sounds like this: There is a
website, running Django, using Django's CSRF protection, in which all
of the form-handling views are only accessible over HTTPS, but there
are other resources in the same domain (or its subdomains) which are
accessible over HTTP.

Further, there is an attacker, who can sniff the unencrypted HTTP
traffic, and can construct an HTML page at a different site (this is
Cross-Site Request Forgery, after all)

A lot of the potential damage seems to be mitigated by another check
in django/middleware/csrf.py, for HTTPS requests only, that inpects
the referer header of the incoming request, to ensure that the browser
was not submitting the form from a different site. To get around that,
the attacker would have to be able to construct a form on the
SSL-protected site (a serious html-injection vulnerability would have
to be present), or cause the request to be submitted over plain HTTP
-- but the site is already HTTPS-only, so there shouldn't be any
form-handling code listening on that port.

Does this threat model correspond to what you're thinking? If so, I
don't see away around the CSRF protection (at least, not one that
involves the victim's browser)


-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: csrf cookie security

[Brian Craft]

I thought, rather, that the csrf token was a cookie that was put in a
hidden form field.

With firebug or webkit dev tools you can see the django csrf token in
the cookies. I would also refer you to middleware/csrf.py, where you
can see it doing the set_cookie.

I thought the security of the csrf token relied on the fact that the
3rd party wouldn't know what value to put in the hidden form field.
The csrf middleware is, I believe, validating the value in the form
field, against the value in cookie. But when it creates the form, it
uses the value in the cookie.

If the token is stored in an insecure cookie, it can be sniffed. Then
I don't understand what prevents the attacker from constructing a
valid form.


On Wed, Feb 9, 2011 at 11:36 AM, Ian Clelland  wrote:
> On Wed, Feb 9, 2011 at 11:23 AM, Brian Craft  wrote:
>> I notice that the csrf token is not secure, i.e. the Set-Cookie is
>> constructed w/o the "secure" option, so the browser will send it
>> in-the-clear. It's trivial, then, for a 3rd party to discover the csrf
>> token.
>>
>> Am I missing something?
>
> The CSRF token isn't a cookie (or at least, it shouldn't be) -- it's a
> form field. The security principle behind the CSRF token isn't so much
> that it's not discoverable, as much as that an attacker can't
> construct a link that gets your browser to submit it to the server.
>
> If you site is under SSL (you're talking about secure-only cookies, so
> I presume that this is the case,) then the CSRF token should only
> appear in the HTML forms that the server sends to your browser, and
> the POST requests that your browser makes back, both of which should
> be protected.
>
> If the CSRF token was set in a cookie, then it would be sent with
> every single request that the browser made, and it really would be
> trivial for an attacker to get you to make a valid request of the web
> server, whether he could discover the contents of that cookie or not.
> (SSL wouldn't even help; he could construct an https:// link just as
> easily.) That's not how it's supposed to be set up, though.
>
> --
> Regards,
> Ian Clelland
> 
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: csrf cookie security

[Ian Clelland]

On Wed, Feb 9, 2011 at 11:23 AM, Brian Craft  wrote:
> I notice that the csrf token is not secure, i.e. the Set-Cookie is
> constructed w/o the "secure" option, so the browser will send it
> in-the-clear. It's trivial, then, for a 3rd party to discover the csrf
> token.
>
> Am I missing something?

The CSRF token isn't a cookie (or at least, it shouldn't be) -- it's a
form field. The security principle behind the CSRF token isn't so much
that it's not discoverable, as much as that an attacker can't
construct a link that gets your browser to submit it to the server.

If you site is under SSL (you're talking about secure-only cookies, so
I presume that this is the case,) then the CSRF token should only
appear in the HTML forms that the server sends to your browser, and
the POST requests that your browser makes back, both of which should
be protected.

If the CSRF token was set in a cookie, then it would be sent with
every single request that the browser made, and it really would be
trivial for an attacker to get you to make a valid request of the web
server, whether he could discover the contents of that cookie or not.
(SSL wouldn't even help; he could construct an https:// link just as
easily.) That's not how it's supposed to be set up, though.

-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

csrf cookie security

[Brian Craft]

I notice that the csrf token is not secure, i.e. the Set-Cookie is
constructed w/o the "secure" option, so the browser will send it
in-the-clear. It's trivial, then, for a 3rd party to discover the csrf
token.

Am I missing something?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.