On Wed, Mar 11, 2009 at 10:36 AM, Ashish Tonse <span dir="ltr"><<a href="mailto:ashish.tonse@gmail.com">ashish.tonse@gmail.com</a>></span> wrote:<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;">
Regarding the generation of the hash, would s:token also address the possibility of replay attacks? (Where the same request can be sent multiple times without having to modify the contents, but still have a malicious effect). If it doesn't, I would consider looking at also generating a random number when rendering s:token, and that random number is stored on the server viewstate and client side (for each request), and used in calculating the hash. This number would change with each request.<br>
<br> If this is already address issue, please ignore. My knowledge of internal JSF workings (form client ID for example), is limited compared to that of hashing/replay attacks/etc.</blockquote><div><br>It's a valid concern. Currently in Seam, reply attacks are only addressed if you end the conversation in the POST (hence the conversation id is no longer valid and Seam will abort the request). But yes, let's work out exactly what gets added when. The details help this move along.<br>
<br>The problem I see is that in client-side state saving, at least, the view is controlled by the client, so you can't change the view-scope because the client is providing it. It would work with server-side state saving since the server controls the view scope. A random number would be stored in the form each time it is rendered and that random number is also included in the view signature. That number would then be used when recreating the hash during decode.<br>
<br>UIForm#setAttribute("renderStamp", randomValue);<br><br>sha1( signature = contextPath + "," + viewId + "," + formClientId + "," + renderStamp, salt = browserUid )<br><br>So basically, this is inconsequential in client-side state saving, but will harden server-side state saving.<br>
<br>-Dan<br></div></div><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>