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

Roger Kitain roger.kitain at oracle.com
Tue Sep 21 13:15:46 EDT 2010


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



More information about the jsr-314-open-mirror mailing list