[seam-dev] JSF and CSRF

[Dan Allen]

>
>> 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).

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.

-Dan

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090311/9b7045a2/attachment.html