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

[Roger Kitain]

  Can you please explain how the "BOTH" config option will work?

On 9/27/10 5:12 PM, Kito Mann wrote:
> On Tue, Sep 21, 2010 at 1:15 PM, Roger Kitain <roger.kitain at oracle.com 
> <mailto: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
>
>


-- 
roger.kitain at oracle.com
https://twitter.com/rogerk09
http://www.java.net/blogs/rogerk

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