Hello Roger,<br><br>Regardless of which option we use, shouldn't this be controllable via a context parameter (defaulting to true)?<br><br clear="all">---<br>Kito D. Mann | twitter: kito99 | Author, JSF in Action<br>Virtua, Inc. | <a href="http://www.virtua.com">http://www.virtua.com</a> | JSF/Java EE training and consulting<br>
<a href="http://www.JSFCentral.com">http://www.JSFCentral.com</a> - JavaServer Faces FAQ, news, and info | twitter: jsfcentral<br>+1 203-404-4848 x3<br><br>Sign up for the JSFCentral newsletter: <a href="http://oi.vresp.com/?fid=ac048d0e17">http://oi.vresp.com/?fid=ac048d0e17</a><br>
<br>
<br><br><div class="gmail_quote">On Tue, Sep 21, 2010 at 1:15 PM, Roger Kitain <span dir="ltr"><<a href="mailto:roger.kitain@oracle.com">roger.kitain@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
There are two proposals for enhancing CSRF attacks in JSF. We need to pick one.<br>
<br>
Proposal 1: Form Action URL Approach (Approach provided by Kito Mann)<br>
<br>
This approach does the following: - Token is generated on the server consisting (minimally) of a randomly generated "secret key<br>
(stored in session).<br>
- ViewHandler.getActionURL method must include the token parameter<br>
named "javax.faces.Token", and whose value is the token value.<br>
- At render time this token will be included in Form's action URL - and it will be<br>
posted back to the server.<br>
- Restore View Phase processing compares the incoming token request parameter value<br>
with the token value generated from the secret key in the session.<br>
<br>
Spec Document Modifications:<br>
<br>
Section 7.5.1:<br>
<br>
getActionURL:<br>
<br>
"The URL must contain the parameter constant defined by ResponseStateManager.VIEW_TOKEN_PARAM<br>
The value of this parameter must be a cryptographically produced value minimally consisting<br>
of a "secret key". The "secret key" is a random generated value that was stored in the session<br>
(preferably around session creation time). Implementations may also choose to combine other<br>
values with the secret key to produce a more complex token."<br>
<br>
Section 2.2.1<br>
<br>
"Verify the "javax.faces.Token" request parameter value is the same as the token value generated<br>
from the "secret key" stored in the session. If the values do not match, throw a meaningful<br>
exception."<br>
<br>
<br>
Proposal 2: Form Hidden Field Approach<br>
<br>
This approach is similar to Approach 1, except a Form hidden field "javax.faces.Token"<br>
is used instead of appending to the Form's Action URL.<br>
<br>
Spec Document Modifications:<br>
<br>
Standard RenderKit Docs<br>
<br>
- Form Rendering<br>
<br>
"Render a hidden field named "javax.faces.Token" using the ResponseStateManager.VIEW_TOKEN_PARAM<br>
constant. The value of this hidden field is a cryptographically produced value that must at least<br>
consist of a "secret key". The "secret key" is a random generated value that was stored in the<br>
session (preferably around session creation time). Implementations may also choose to combine<br>
other values with the secret key to produce a more complex token."<br>
<br>
Specification Document<br>
<br>
Section 2.2.1<br>
"Verify the "javax.faces.Token" request parameter value is the same as the token value generated<br>
from the "secret key" stored in the session. If the values do not match, throw a FacesException.<br>
<br>
<br>
For both approaches see:<br>
<br>
<br>
[1] <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869</a><br>
<br>
Look at the two latest change bundles attached to the issue.<br>
<br>
Please review by COB Friday as we have no time left for 2.1.<br>
<br>
Kudos to Kito Mann for helping out with the implementation.<br><font color="#888888">
<br>
-roger<br>
</font></blockquote></div><br>