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

[Kito Mann]

Hello Neil,

Wouldn't it possible to just avoid adding the token when the application is
inside of a portlet environment?
---
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 4:20 PM, Neil Griffin <neil.griffin at portletfaces.org
> wrote:

> #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/20100927/95ad3d40/attachment-0002.html