[WEB SECURITY] CSRF protection: What are the benefits of using the Synchronizer Token Pattern if your application is not vulnerable to XSS and using HTTPS only?
jim at manico.net
Sat Apr 23 18:56:27 EDT 2011
I think this (double-cookie submit) is a weak defensive choice since
it requires that a browsers single-origin policy to be perfect, and
history says otherwise. I feel that a cryptographic nonce, either
per-session or per-request, is a more robust defense.
Admittedly, supporting tokens on a per-request basis does require
storing a queue of tokens - which can be tricky to get right for a
number of reasons. I think one token per session is a reasonable
tradeoff for a framework.
If storing nonces is an issue, which I've seen in a few SSO
environments, then a "stateless nonce" (ie: use the hash of the
session ID) is a solid "second choice" for CSRF protection.
The double-cookie submit always seemed like the least secure approach
to me, but many disagree...
I'm very glad that Django cares about this topic, thank you Paul.
On Apr 20, 2011, at 1:00 PM, Paul McMillan <paul at mcmillan.ws> wrote:
> In the Django web framework, we concluded that the cost of doing a
> server side verification was too high for precisely these reasons.
> Instead, we use a mostly client side CSRF solution.
> -We only accept POST requests for actions that change application state.
> -Each form we render includes a hidden csrftoken field
> -We set a matching csrftoken cookie
> -server-side, we compare the posted value to the value sent as a cookie
> This works because an attacker can't set a cookie in a user's browser
> for my domain.
> This lets us do CSRF independent of the session, and prevents us from
> storing large token tables for requests that may never happen.
> On Wed, Apr 20, 2011 at 1:50 AM, Richard Hauswald
> <richard.hauswald at googlemail.com> wrote:
>> I'm playing around with different AJAX based web technologies in a
>> spare time project. I managed to implement the Synchronizer Token
>> Pattern to fully comply to the OWASP recommendation.
>> Now I'm on my way playing around with load balancing. I managed to
>> implement a "sticky" variant where the user is bound to a particular
>> server instance for the lifetime of the session. But if I try to
>> balance each request to a different machine I ran into random errors
>> when doing heavy stress testing.
>> I isolated to problem to the following: The session distribution
>> between the server instances is sometimes not fast enough to
>> synchronize new token stored in the session. This leads to false
>> positives in the anti CSRF token Filter/Interceptor.
>> This could be easily fixed by using a session wide anti CSRF token
>> which is not regenerated with every request. But this violates the
>> OWASP recommendation :-( I googled and thought a lot about the
>> What are the benefits of using the Synchronizer Token Pattern if your
>> application is not vulnerable to XSS and using HTTPS only?
>> My conclusion is that if one is using HTTPS and a web application
>> which is not vulnerable to XSS attacks there is not benefit of
>> regenerating the anti CSRF token with each request compared to a
>> session wide token. Is this conclusion correct?
>> Best Regards,
>> Richard Hauswald
>> Blog: http://tnfstacc.blogspot.com/
>> LinkedIn: http://www.linkedin.com/in/richardhauswald
>> Xing: http://www.xing.com/profile/Richard_Hauswald
>> The Web Security Mailing List
>> WebSecurity RSS Feed
>> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>> WASC on Twitter
>> websecurity at lists.webappsec.org
> The Web Security Mailing List
> WebSecurity RSS Feed
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> websecurity at lists.webappsec.org
More information about the websecurity