+1 for both points.<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 28, 2010 at 4:17 PM, Roger Kitain <span dir="ltr">&lt;<a href="mailto:roger.kitain@oracle.com">roger.kitain@oracle.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 Comments inline..<div class="im"><br>
On 9/28/10 2:56 PM, Alexander Smirnov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The #2 approach is already here, it&#39;s JSF view state field. It would be<br>
make even stronger by some random string added to its value, but that<br>
doesn&#39;t require any change in spec; the format of state field is up to<br>
implementation.<br>
</blockquote></div>
Yep - I agree that we could possibly augment the view state with some generated<br>
random value.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The #1 is also available as custom view parameter, but we can make it<br>
more convinient as implicit view parameter and  metadata control<br>
included in all ( or selected ) navigation links and views. It would<br>
leverage already existing JSF 2.0 features. As well as view parameters<br>
processed in the separate ExternalContext method, they are portlet-safe.<br>
</blockquote></div>
Hmm... They are probably many ways to slice and dice this problem.<br>
I think we were looking for a more automatic solution then having to introduce<br>
more burden on page authors or application developers.<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 09/21/2010 10:15 AM, Roger Kitain wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are two proposals for enhancing CSRF attacks in JSF.  We need to<br>
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<br>
server consisting (minimally) of a randomly generated &quot;secret key<br>
      (stored in session).<br>
    - ViewHandler.getActionURL method must include the token parameter<br>
      named &quot;javax.faces.Token&quot;, and whose value is the token value.<br>
    - At render time this token will be included in Form&#39;s action URL -<br>
and it will be<br>
      posted back to the server.<br>
    - Restore View Phase processing compares the incoming token request<br>
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>
&quot;The URL must contain the parameter constant defined by<br>
ResponseStateManager.VIEW_TOKEN_PARAM<br>
The value of this parameter must be a cryptographically produced value<br>
minimally consisting<br>
of a &quot;secret key&quot;. The &quot;secret key&quot; is a random generated value that was<br>
stored in the session<br>
(preferably around session creation time).  Implementations may also<br>
choose to combine other<br>
values with the secret key to produce a more complex token.&quot;<br>
<br>
Section 2.2.1<br>
<br>
  &quot;Verify the &quot;javax.faces.Token&quot; request parameter value is the same as<br>
the token value generated<br>
    from the &quot;secret key&quot; stored in the session.  If the values do not<br>
match, throw a meaningful<br>
    exception.&quot;<br>
<br>
<br>
Proposal 2: Form Hidden Field Approach<br>
<br>
This approach is similar to Approach 1, except a Form hidden field<br>
&quot;javax.faces.Token&quot;<br>
is used instead of appending to the Form&#39;s Action URL.<br>
<br>
Spec Document Modifications:<br>
<br>
Standard RenderKit Docs<br>
<br>
- Form Rendering<br>
<br>
&quot;Render a hidden field named &quot;javax.faces.Token&quot; using the<br>
ResponseStateManager.VIEW_TOKEN_PARAM<br>
  constant.  The value of this hidden field is a cryptographically<br>
produced value that must at least<br>
  consist of a &quot;secret key&quot;.  The &quot;secret key&quot; is a random generated<br>
value that was stored in the<br>
  session (preferably around session creation time).  Implementations may<br>
also choose to combine<br>
  other values with the secret key to produce a more complex token.&quot;<br>
<br>
Specification Document<br>
<br>
Section 2.2.1<br>
   &quot;Verify the &quot;javax.faces.Token&quot; request parameter value is the same as<br>
the token value generated<br>
    from the &quot;secret key&quot; stored in the session.  If the values do not<br>
match, throw a FacesException.<br>
<br>
<br>
For both approaches see:<br>
<br>
<br>
[1]<br>
<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>
</blockquote></blockquote>
<br>
<br></div></div><div><div></div><div class="h5">
-- <br>
<a href="mailto:roger.kitain@oracle.com" target="_blank">roger.kitain@oracle.com</a><br>
<a href="https://twitter.com/rogerk09" target="_blank">https://twitter.com/rogerk09</a><br>
<a href="http://www.java.net/blogs/rogerk" target="_blank">http://www.java.net/blogs/rogerk</a><br>
<br>
</div></div></blockquote></div><br>