<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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).<br>
<br>
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:<br>
<br>
sha1( signature = viewId + "," + formClientId, salt = clientUid )<br>
<br>
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)<br>
<br>
sha1( signature = viewId + "," + formClientId + "," + sessionId, salt = clientUid )</blockquote></div></div></blockquote><div><br>Christian asked two questions about this, which I will answer here.<br>
<br>What happens when cookies are not enabled?<br><br>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).<br>
<br>Did you come up with this idea yourself?<br><br>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 (<a href="http://www.isecpartners.com/files/XSRF_Paper_0.pdf">http://www.isecpartners.com/files/XSRF_Paper_0.pdf</a>) Having said that, I implemented something similar in an application I worked on.<br>
<br>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.<br><br>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).<br>
<br></div></div>Please note that this solution isn't a complete panacea. If your site is vulnerable to XSS, then the browser Uid can be revealed. Then again, once the session ends, you get a new one anyway.<br><br>-Dan<br clear="all">
<br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>from my email. If you contact me, but don't hear back for more than a week,<br>
it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>you feel that it did not reach my attention.<br>