Alexander,
I think that you are saying that for POST requests, we should fix up the
view state token and that for GET requests, we can leverage the
UIViewParam support for the actual checking.
For the GET support, I am worried about the amount of work to enable
this on the affected pages (for Applications that mostly live behind a
log-in, this could be all of the pages except the log-in). Also, the
easiest implementation (the secret) is the least secure as it is
possible (though not easy) to take advantage of referer leakage is the
user is on a page with the hidden secret in its URL and clicks on a link
to a malicious site (the best way to do so would probably be to get the
malicious content served through an advertising service displaying
content on the page).
-- Blake Sullivan
On 7/25/11 8:24 PM, Alexander Smirnov wrote:
> My opinion to use existing viewState parameter comes from frameworks
> internals; adding one more hidden parameter could break some existing
> libraries that relays on javax.faces.ViewState ( the only required by
> current spec ), so that's matter of backward compatibility.
> Fo GETJSF 2 already has appropriate "view parameter" that can be used
> to check secure token. It can be special Validator or component that
> extends UIViewParam ( or coming UIViewAction ? ) and blocks access to
> page without proper token. Everything already there to implement such
> protection and make it configurable per page.
>
>
> On Mon, Jul 25, 2011 at 6:43 PM, Blake Sullivan
> <blake.sullivan_at_oracle.com> wrote:
>> Kito,
>>
>> I understand that solving GET would be nice. However, the GET problem only
>> affects GET pages with side-effects--the application developer has control
>> over the extent to which this affects her. The POST problem affects every
>> developer and is therefore more pressing and easily solved by making the
>> view state token cryptographically strong and choking in restore view--in
>> fact Trinidad and I'm sure other frameworks already do this.
>>
>> On the GET side, we have two problema--one implementation and one
>> controlling which pages this applies to (or doesn't apply to). I laid out
>> the implementation possibilities. The problem of determining when to apply
>> is that any page that needs to be directly accessible from outside the
>> application can not have this check applied to it, but JSF doesn't currently
>> keep track of valid external entry points.
>>
>> If we don't want the application author to turn on or off individual pages,
>> I think we end up with either rules for when the check should be applied.
>> If we are specifying rules, should the rules be based purely on the URL? If
>> we are modifying the generated URLs, I worry some about the performance
>> impact of stamped actions. Even if we end up falling back to URL
>> manipulation for GETs, I would prefer that we use referer checking if the
>> referer was present in the HTTP Request that initially created the session,
>> as this doesn't require any URL manipulation.
>>
>> -- Blake Sullivan
>>
>> On 7/25/11 6:21 PM, Kito Mann wrote:
>>
>> On Mon, Jul 25, 2011 at 8:49 PM, Blake Sullivan<blake.sullivan_at_oracle.com>
>> wrote:
>>> As far as controlling which pages this applies to, it seems like kind of a
>>> pain and I would prefer that we look at ways of making this simpler or
>>> possibly combining with other page-level metadata that the application
>>> developers might wish to add.
>> I really think it should be easy to turn this on -- you shouldn't have to
>> earmark every page if you don't want to. The possible attacks using GET
>> requests are pretty well documented, and since JSF apps have no restrictions
>> on what type of actions you can perform, we can't guarantee that people
>> aren't doing updates during GETs.
>>> -- Blake Sullivan
>>>> The
>>>> 20110707 proposal addresses this by enhancing the spec for
>>>> getActionURL. The proposal also addresses GET based pages by allowing
>>>> you to delineate which views in the app are protected and not, and by
>>>> building on the form rendering such that non-protected pages can get to
>>>> protected pages via GET with UIViewParameter elements.
>>>>
>>>> Blake, do you have some specific concerns?
>>>>
>>>> Ed
>>>>
>>
>>
>
>