[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?
john.wilander at owasp.org
Wed Apr 20 17:40:45 EDT 2011
The technique Paul presents is popularly called 'Double Submit and is a nice CSRF protection that doesn't require server-side state.
On the server you can either have a filter on your resources (meaning in the app), or have an intelligent web front handle it and strip cookie and param off. The filter checks that the cookie and parameter match and that they are of the correct format, for instance hex 16 chars.
Anyone else who has tweaks or ideas on how to enhance Double Submit? Love to hear about it!
Skickat från min iPhone
20 apr 2011 kl. 21:07 skrev Paul McMillan <paul at mcmillan.ws>:
> 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