[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?
richard.hauswald at googlemail.com
Wed Apr 20 04:50:50 EDT 2011
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?
More information about the websecurity