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

[Kito Mann]

Hello Roger,

Regardless of which option we use, shouldn't this be controllable via a
context parameter (defaulting to true)?

---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3

Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17



On Tue, Sep 21, 2010 at 1:15 PM, Roger Kitain <roger.kitain at oracle.com>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/20100927/02747177/attachment-0002.html