What CSRF attacks will 'First-Party-Only' cookies protect against?

Question

The new 'First-Party-Only' cookie attribute:

... allows servers to assert that a cookie ought to be sent only in a "first-party" context. This assertion allows user agents to mitigate the risk of cross-site request forgery attacks, and other related paths to cross-origin information leakage.

Chrome is planning to implement the feature in chrome #50.

The spec defines First-Party:

... as an HTTP request for a resource whose URL's origin matches the origin of the URL the user sees in the address bar.

Specifically stating:

• New windows create new first-party contexts.

• Full-page navigations create new first-party contexts. Notably, this includes both HTTP and <meta>-driven redirects.

• <iframe>'s do not create new first-party contexts; their requests MUST be considered in the context of the origin of the URL the user actually sees in the user agent's address bar.

So the feature seems to protect against the case when CSRF is used to send a POST request to an <iframe> on the attacker's page. But how about the following CSRF vectors:

1. The CSRF is a link or a javascript navigation to a GET request? The user will see a full navigation, I assume we aren't helped here.
2. The CSRF is a javascript submitted POST but the target of the form causes a full navigation to the victim's site? More likely to be dodgy as the POST comes from somewhere else but it's still a full navigation.

I'm excited about this new Cookie feature but to exactly what extent does it protect against CSRF attacks?

Answer 1

In addition to your own answer, CSRF defences are still recommended and are useful:

"SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client. It is,
however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and
submissions can certainly be executed in conjunction with other
attack vectors such as cross-site scripting.

Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are
idempotent, etc) to mitigate the risk more fully.

Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies.

Although I do disagree with the XSS attack vector, as XSS always trumps a CSRF vulnerability - if an attacker can inject HTML and script they can circumvent most defences (or all defences with a bit of "social engineering" to trick the user into entering passwords or CAPTCHAs when required).

Answer 2

These scenarios are addressed in Version 6 of the spec.

It defines Strict (default) and Lax modes, where strict would not send cookies even for top level navigations, and Lax would send cookies for top level navigations, but wouldn't for "unsafe HTTP methods" including POST.

The answers for the two scenarios are therefore:

1. JS navigations and link clicks would be protected with First-Party-Only cookies, unless using Lax mode.
2. Form POSTs would always be protected as POST is considered unsafe.

So when this is implemented across browsers, are CSRF tokens obsolete?

CSRF tokens are still useful because they can ensure that endpoints can only be called from specific pages on your domain. Where as First-Party-Only cookies can only ensure it comes from the same domain. This means XSS vulnerabilities on a different page to your endpoint can't hit that endpoint.

Answer 3

From reading the section 7.1 "Limitations" I would assume that the author of the RFC is aware of the limitation you describe. First-Party-Only cookies are not seen as the all-encompassing protection against CSRF.

First-Party-Only cookies are only indented to protect against CSRF which are invisible to the end user. This means that it does not intend to protect against CSRF which will result in changing the visible URL, like happens when following a link, submitting a form or getting a redirect using the meta tag or a HTTP response. But they should protect against invisible CSRF which do not change the visible URL and which can be done with the image tag, from within an iframe or similar.