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

[Kito Mann]

+1 for both points.
---
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 28, 2010 at 4:17 PM, Roger Kitain <roger.kitain at oracle.com>wrote:

>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100928/5cced781/attachment-0002.html