Using double submit cookies

[bpapez]

We try to use csrfguard 4.x in our application, which uses clusters with fail-over support for high availability, which means the master/page tokens need to be replicated or at least available by all cluster nodes. For now we use our own TokenHolder implementation based on Hazelcast's ReplicatedMap. We assume that there could be a performance issue especially under high load.

The OWASP Cross-Site Request Forgery Prevention Cheat Sheet mentions that for stateless software or if maintaining the state for CSRF token at server side is problematic, the Double Submit Cookie technique. Would that be somehow possible with csrfguard 4.x or it is not recommended to do it with csrfguard? Is there some existing implementation, which could be used?

[forgedhallpass]

If I remember correctly from our previous discussions, your applications are stateful, which I assume means that you are using HTTP session replication between your nodes. If so, token replication should come with a similar performance penalty. You could try tying the tokens back to the session, so they would be automatically replicated (although it would require changes in the library and you would need to find a way for the TokenHolder interface not to depend on HTTP sessions directly, because that would not make sense in case of stateless web apps).

Have you considered/tried moving the tokens to a database or to an in-memory cache?

At this time, the Double Submit Cookie approach is out of scope for CSRFGuard, because it provides a slightly less secure protection mechanism, and would require significant changes and testing.