Random Request nonce in Spring Security

[CrisLander]

Hi everyone,

I've been looking at Spring Security for authentication and authorization, and there's something I haven't been able to find: A synchronizer token pattern, such as described in the OWASP: http://www.owasp.org/index.php/Cross...oken_Pa ttern

Basically, it works like this: In addition to having a session cookie with a session token, when a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. This random token is included in each user request, and when a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token is not found within the request or the value provided does not match the value within the session, then the request should be aborted and the event logged as a potential CSRF attack in progress. This token can be renewed whenever wanted, going as far as renewing it for every request.

How can I implement this random token in Spring Security? Is it already implemented, and I just haven't found it? Can I create a custom property in the Security Context where I can store the random token for the current user? Bear in mind, this is different than a session token, the idea is that even if someone steals a cookie and compromises a session cookie, they still wouldn't have the security token and thus would be rejected.

[Luke Taylor]

Synchronizer tokens require integration with the actual view technology you are using, so it's not something that is supported by Spring Security.

I'd recommend you take a look at HDIV, which provide this and much more. You can also monitor and vote for this issue.

[CrisLander]

Thanks, I'll check HDIV.

I would've thought this token would be a perfect fit for the security context, and spring security could've implemented a filter to validate it. But maybe with HDIV I'll solve my problems.