[jsr-314-open-mirror] [jsr-314-open] [Spec-869-Specify CSRF Solution] PROPOSAL(s)

[Neil Griffin]

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

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

Neil

On Sep 21, 2010, at 1:15 PM, Roger Kitain wrote:

> 
> There are two proposals for enhancing CSRF attacks in JSF.  We need to pick one.
> 
> Proposal 1: Form Action URL Approach (Approach provided by Kito Mann)
> 
> This approach does the following:      - Token is generated on the server consisting (minimally) of a randomly generated "secret key
>     (stored in session).
>   - ViewHandler.getActionURL method must include the token parameter
>     named "javax.faces.Token", and whose value is the token value.
>   - At render time this token will be included in Form's action URL - and it will be
>     posted back to the server.
>   - Restore View Phase processing compares the incoming token request parameter value
>     with the token value generated from the secret key in the session.
> 
> Spec Document Modifications:
> 
> Section 7.5.1:
> 
> getActionURL:
> 
> "The URL must contain the parameter constant defined by ResponseStateManager.VIEW_TOKEN_PARAM
> The value of this parameter must be a cryptographically produced value minimally consisting
> of a "secret key". The "secret key" is a random generated value that was stored in the session
> (preferably around session creation time).  Implementations may also choose to combine other
> values with the secret key to produce a more complex token."
> 
> Section 2.2.1
> 
> "Verify the "javax.faces.Token" request parameter value is the same as the token value generated
>   from the "secret key" stored in the session.  If the values do not match, throw a meaningful
>   exception."
> 
> 
> Proposal 2: Form Hidden Field Approach
> 
> This approach is similar to Approach 1, except a Form hidden field "javax.faces.Token"
> is used instead of appending to the Form's Action URL.
> 
> Spec Document Modifications:
> 
> Standard RenderKit Docs
> 
> - Form Rendering
> 
> "Render a hidden field named "javax.faces.Token" using the ResponseStateManager.VIEW_TOKEN_PARAM
> constant.  The value of this hidden field is a cryptographically produced value that must at least
> consist of a "secret key".  The "secret key" is a random generated value that was stored in the
> session (preferably around session creation time).  Implementations may also choose to combine
> other values with the secret key to produce a more complex token."
> 
> Specification Document
> 
> Section 2.2.1
>  "Verify the "javax.faces.Token" request parameter value is the same as the token value generated
>   from the "secret key" stored in the session.  If the values do not match, throw a FacesException.
> 
> 
> For both approaches see:
> 
> 
> [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
> 
> Look at the two latest change bundles attached to the issue.
> 
> Please review by COB Friday as we have no time left for 2.1.
> 
> Kudos to Kito Mann for helping out with the implementation.
> 
> -roger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100921/d2315c2b/attachment-0002.html