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.
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.
Ashish Tonse
On Wed, Mar 11, 2009 at 10:23 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Issue created and initial concept patch provided here
https://jira.jboss.org/jira/browse/JBSEAM-4007
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev