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

Blake Sullivan blake.sullivan at oracle.com
Tue Oct 26 20:04:11 EDT 2010 

On 10/25/10 11:56 PM, Martin Marinschek wrote:
> Hi Blake,
>
>> This is a pile of new functionality and the question is, and I'm curious
>> what the application would do with this functionality.  What is the
>> problem that the application is trying to avoid?
> Problem 1: double submit, refresh handling. Not every application
> wants to do the same thing here, we would allow the application to
> handle this the way it wants.
By double submit, which cases:
1) User accidentally presses the button twice
2) User hits back to a POST
3) User hits reload on a POST

For refresh handling, what is the use case where you want to deal with 
reload differently than the initial render?
> Problem 2: what happens if (in server-side state-saving) the
> view-states run out while you go back through the history? JSF does
> anything (depending on the release), but never something which is a)
> the same across all versions b) makes sense c) is influencable by the
> user.
I agree that we need to decide how this should work as well as what 
should happen if we receive a token we've never seen and that this needs 
to be part of the 2.1 release.
> Problem 3: Treating browser back as applicatory back: as an
> application developer, I would love to have a way to treat the browser
> back as an applicatory back instead of a mere browsing in the history
> of pages displayed.
Why can't you do that today?
>>> I agree with other commenters that the CSRF protection really makes
>>> only sense per view - or actually, and this is hopefully a right
>>> assumption, per what the view does.
>> But I don't think it is a per-view.  Isn't it potentially per action?
> Yes - but, if we consider the post case covered, no actions are gonna
> be executed on a CSRF-call, except for view-actions or pre-render
> callbacks. So its more a view-level action I am talking about, that's
> what I meant with "what the view does".
I must admit that I haven't looked at the view-actions enough, but can't 
I have some view actions that are idempotent and others that aren't.  
I'm mostly worried about squeezing in something that we haven't fully 
thought out.
> In any case, I am not advocating that this needs to be in right away
> and is absolutely necessary, I just advocate that if we add something
> for CSRF protection which necessitates a new token-API, we might want
> to do it proper and cover these other issues as well.
I agree that if we added a new per-request token we should look at the 
rest of the cases.  I just don't think we have time to do everything 
that we would need to for this release.

-- Blake Sullivan
> best regards,
>
> Martin
>
>>> On 10/22/10, Blake Sullivan<blake.sullivan at oracle.com>   wrote:
>>>>     On 10/22/10 11:10 AM, Roger Kitain wrote:
>>>>>    Hey Blake -
>>>>>
>>>>> Thanks for responses..
>>>>>
>>>>> On 10/22/10 12:51 PM, Blake Sullivan wrote:
>>>>>>    Roger,
>>>>>>
>>>>>> Di you answer Alexander's question regarding whether this feature is
>>>>>> even necessary?  In the current releases, with no explicit CSRF
>>>>>> defenses, we have attacks against:
>>>>>> 1) GET attack
>>>>>> 2) POST attack against a page with token state saving
>>>>>> 3) POST attack against a page with client state saving
>>>>> Yes.  By number 2 - I presume you are talking about server side state
>>>>> saving.
>>>>>> 1) For GET attacks, it appears that we are saying that we aren't
>>>>>> going to defend against these anyway for this release.
>>>>> Yes. It's a bit trickier as we may need to do this on a page by page
>>>>> basis.
>>>> I think that it is trickier than that--you need to worry about things
>>>> like your parameter leaking out through the referer header.  At this
>>>> point, I don't see how you would get the spec work done in time.  Plus,
>>>> a well written web application won't have side-effects on the GET
>>>> anyway.  The CSRF attacker can GET all day and not change the
>>>> application state.
>>>>>> 2) For POST attacks against a page with token state saving.  As long
>>>>>> as the view state token is cryptographically strong, the attacker
>>>>>> can't guess the token anyway.  At that point, it comes down to what
>>>>>> the behavior is for a request that has an invalid token--we can
>>>>>> either return an error page or we can treat the request as a GET.  If
>>>>>> we treat the request as a GET, we are in 1
>>>>> For server side state saving by default, the view state is not as
>>>>> strong.
>>>>>     So we were looking at
>>>>> this CSRF "extra token" approach as facilitating the view state for
>>>>> CSRF solution.  However, there are ways to make the server side view
>>>>> state stronger - in which case there may not
>>>>> be a need for an extra token to augment the view state.  For now it
>>>>> may be as simple as a clarification
>>>>> (recommendation) in the spec about the server side view state being
>>>>> cryptographically strong - I'd have
>>>>> to check the spec to see what is there.
>>>> Yep.  Make it cryptographically strong, as it is in Trinidad and you are
>>>> done with the server-side storage POST except for figuring out what to
>>>> do if the token isn't valid.  I see no need to add yet another token
>>>> when the existing one will do.
>>>>>> 3) For POST attacks against a page with client state saving, as long
>>>>>> as attackers can't forge the client state, they can't do anything.
>>>>>> Since, they can't, we're safe here as well.
>>>>> Yes, client side view state is cryptographically strong.
>>>> Yep
>>>>>> Therefore, it isn't clear what the feature is buying us.  If there is
>>>>>> no clear need for the feature, it should not be added to the
>>>>>> specification.
>>>>> If we are deferring GET CSRF handling, and possibly adding a spec
>>>>> clarification for server side view state, then I agree.
>>>> Cool
>>>>
>>>> -- Blake Sullivan
>>>>
>>>>>> -- Blake Sullivan
>>>>>>
>>>>>>
>>>>>> On 9/21/10 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
>>
>

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