<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">#1 is probably not compatible with portlets. Portals are in full control of creation of URLs in general, and it is not possible to simply append "&javax.faces.Token=XYZ" to a portal's ActionURL and expect it to work.<div><br></div><div>#2 is compatible with portlets, but it would be best to have the hidden field namespaced. Otherwise it would be like javax.faces.VIEW_ID which is not namespaced, and can cause problems in portals.</div><div><br></div><div>Neil<br><div><br><div><div>On Sep 21, 2010, at 1:15 PM, Roger Kitain wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><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">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><br>-roger<br></div></blockquote></div><br></div></div></body></html>