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

[Kito Mann]

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

Why? I think it's actually safer to allow both:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL.
According to this, appending the token works better when you can't guarantee
that a server-side operation is occurring only through POST. Especially with
the new capabilities of JSF 2 for parsing view parameters, I don't think we
can make this guarantee.

Also, the rewriting approach is what they're using for the generic filter in
Tomcat 7:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL.
I was talking to Mark Thomas, the guy working on this feature, about this at
JavaOne. As you can see, it doesn't even look like they're using the hidden
field approach (probably because it'd be very hard to implement in a generic
fashion).

 So, I think we should provide both features, but give the users to turn off
either algorithm, with a context parameter such as:

javax.faces.CSRF_ALGORITHM=NONE | FORM | URL | BOTH (or ALL)

Thoughts?


>
> 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/a0e266ba/attachment-0002.html