The first step is to assign a unique identifier to the browser in the form of a cookie (javax.faces.ClientUid). This is similar to the session id, only it is established once for each browser session (until the user closes the browser). As you may know, there is no dependable way to identify a browser. So we are assigning it unique identifier so that there is. This unique identifier will be used as a salt when generating the token and can only be known by the browser (never visible to an attacker under normal circumstances).

The next step is to generate a token for the form, which is a hashed version of the view signature. That hash is calculated as follows:

sha1( signature = viewId + "," + formClientId, salt = clientUid )

The developer can also choose to incorporate the session id into this hash for a more secure token (at the cost of binding it to the session)

sha1( signature = viewId + "," + formClientId + "," + sessionId, salt = clientUid )

Christian asked two questions about this, which I will answer here.

What happens when cookies are not enabled?

I just don't know how we can deliver this level of security without cookies. As with public/private key authentication, there has to be information that the primary exchange is not privy to (the cookie being the secondary, private exchange).

Did you come up with this idea yourself?

This is an adaptation of the recommendation called Keyed‐Hashing for Message Authentication that is referenced in the Cross Site Reference Forgery by Jesse Burns (http://www.isecpartners.com/files/XSRF_Paper_0.pdf) Having said that, I implemented something similar in an application I worked on.

As for JSF 2, it would be nice to make this part of <h:form>. We also assume/hope that the view state id for server-side state saving is going to become a random number.

We can also apply this solution to Seam Remoting. Page actions are a different story since I argue that securing them is up to the application developer or may not be necessary. For instance, an e-mail validation link is secure in that the link is temporary with a secret code and private to an e-mail inbox. Page actions that validate a resource id also don't need to be secured (is this book id a valid isbn).