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

[Roger Kitain]

  Comments inline..
On 9/28/10 2:56 PM, Alexander Smirnov wrote:
> The #2 approach is already here, it's JSF view state field. It would be
> make even stronger by some random string added to its value, but that
> doesn't require any change in spec; the format of state field is up to
> implementation.
Yep - I agree that we could possibly augment the view state with some 
generated
random value.
> The #1 is also available as custom view parameter, but we can make it
> more convinient as implicit view parameter and  metadata control
> included in all ( or selected ) navigation links and views. It would
> leverage already existing JSF 2.0 features. As well as view parameters
> processed in the separate ExternalContext method, they are portlet-safe.
Hmm... They are probably many ways to slice and dice this problem.
I think we were looking for a more automatic solution then having to 
introduce
more burden on page authors or application developers.
>
>
> On 09/21/2010 10:15 AM, 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


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