Re: csrf cookie security

[Ian Clelland]

On Thu, Feb 10, 2011 at 5:21 AM, Lior Sion <lior.s...@gmail.com> 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:
>
> <img src="<a href="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</a>" />
> 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
<clell...@gmail.com>

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