[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?

Paul McMillan paul at mcmillan.ws
Wed Apr 20 15:07:47 EDT 2011

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:
> Hello,
> 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
> question:
> 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
> --
> 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
> http://www.webappsec.org/rss/websecurity.rss
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> http://twitter.com/wascupdates
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

More information about the websecurity mailing list