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.

Reply via email to