On 7/25/11 1:33 PM, Ed Burns wrote:
>>>>>> On Fri, 22 Jul 2011 17:50:21 -0700, Blake Sullivan<blake.sullivan_at_oracle.com> said:
> B> Ed,
> B> It may have been at the 24th hour, but I believe that Alexander is
> B> correct. If we are only applying CSRF protection to form POSTs, why
> B> isn't the view state token completely sufficient? If we are attempting
> B> to apply CSRF protection to GETs, there are other issues that are going
> B> to crop up.
>
> We want to apply it to any views to which the user wants it applied,
> regardless of GET or POST. I understand that the existing view state
> token takes a lot of the way there for pages using POST, however, there
> is no requirement that the view token be cryptographically strong.
Ed,
Why do you believe that the ViewState token does not have to be
cryptographically strong? It would seem that the argument for why it
doesn't need to be cryptographically strong is that without cracking the
session id, it doesn't matter. However, we should making it
cryptographically strong helps prevent session fixation attacks and is
easy, so why wouldn't we? Do you disagree with the statement that a
cryptographically strong ViewState token handles the POST request case?
This leaves the GET case and I'm wondering what kinds of GET attacks you
are worried about. GETs with no behavioral side-effects should be
fine. As far as implementation, adding a secret to the URL has
potential problems with referer leakage. Checking the "referer" header
can have problems with proxies stripping the "referer" MACing the URL
parameters does work but makes client-side URL construction
significantly more complicated.
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.
-- 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
>