Hello Neil,<br><br>Wouldn't it possible to just avoid adding the token when the application is inside of a portlet environment?<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 4:20 PM, Neil Griffin <span dir="ltr"><<a href="mailto:neil.griffin@portletfaces.org">neil.griffin@portletfaces.org</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;">
<div style="word-wrap: break-word;">#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><font color="#888888">Neil</font><div><div></div><div class="h5"><br><div><br><div><div>On Sep 21, 2010, at 1:15 PM, Roger Kitain wrote:</div><br><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" 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><br>-roger<br></div>
</blockquote></div><br></div></div></div></div></div></blockquote></div><br>