Re: Proposed CSRF countermeasure

On Sun, Aug 18, 2013 at 12:54 PM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

> > This is intended to affect cross-origin requests made by a browser.
>
> In your proposal, what constitutes a cross-origin request? While the case
> of <iframe> or <script> subresources are clear, would a 'self' policy
> prevent third-party sites from as little as providing a fully-working link
> to a protected application?
>

If I understand the question, this speaks to site design and whether app
developers might find this policy workable or not. The intention is to
prevent the cookie from accompanying direct links into a resource that
performs some authenticated/authorized action (in other words, "breaking"
the functionality of the link). The idea behind 'self' as opposed to
'isolate' would be for direct links into a resource that a dev considers
"safe" or without a CSRF danger, for which they could make an exception and
allow a cookie.

This was one of the reasons for applying a policy on a per-cookie basis, so
that certain contexts could be maintained cross origin. I suspect this
would turn into a situation that would work great for certain kinds of
sites with compartmentalized content, but not for others. The Wordpress
scenario, where /wp-admin/ would be protected was a positive example for
this. I haven't yet listed counterexamples against this, but omission
wasn't meant to imply they don't exist.



>
> What would be the behavior for requests made from origins such as
> data:text/html,...?
>

I haven't examined the origin handling of data URLs and what Origin would
be assigned to it (null, browsing context, parent resource, etc.). The
desire would be to prevent data URLs from being used as an attack vector
(in terms of including a cookie) when contained in a resource from a
different Origin. This question needs a clearer answer; I've noted it for a
follow up.



>
> Note a possible incompatibility between meta referrer=never and preflight
> requests.
>

Noted. My understanding is that the browser still has knowledge of the
Origin and would therefore be able to make a policy decision.


>
> Also note that such protections would be inherently ineffective for GET
> XSRF on sites that:
>
> 1) Use internal redirectors. Any sites that accepts something like
> /foo?returnURL=/local_path/ (this does not have to be an open redirector,
> just a site-scoped one) would be vulnerable.
>

This was highlighted as a concern and is a weakness. Right now, the
security burden would have to be shifted back to the developer who would
need to address the redirector's behavior.


>
> 2) Permit user-controlled links of any sort (webmail systems, social
> networks, online forums, and a good chunk of other complex web apps).
>
> /mz
>

These also fall into the task of surveying real-life apps to find design
patterns that work or don't work with such a policy. In some cases, these
might be CSRF-protected using "non-simple" GET requests with CORS and a
custom header. But that goes back to a burden on development and only
applies to browsers that support CORS. The other question is which kinds of
apps expect arbitrary linking-in and which ones expect more isolated,
same-origin activity.

I'll follow-up with more use cases as well as clearer scenarios where the
policy would be difficult or impossible to apply (and any tweaks that might
resolve such problems).

Thanks,
Mike