4

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?

Improve this question
3

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 from the same Origin, 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).

However, as jub0bs poins out, subdomains with vulnerabilities may be an additional attack vector.

Improve this answer
5
  • Your point about XSS makes sense, and now I'm unsure under what scenarios CSRF tokens could add any extra security on top of SameSite cookies? Ignoring the usage of old browsers etc. etc. – George Powell Feb 4 '16 at 12:26
  • I would probably say that it would still be required for old or unsupported browsers. – SilverlightFox Feb 4 '16 at 12:29
  • 1
    @SilverlightFox "[...] as same-site navigations and submissions can certainly be executed in conjunction with other attack vectors such as cross-site scripting." This passage of the draft is frequently misunderstood: the draft warns, not about XSS on the origin to be defended, but on different origins that happened to be on the same site. I've written about this: jub0bs.com/posts/2021-01-29-great-samesite-confusion – jub0bs Mar 27 at 12:40
  • 1
    @jub0bs Nice post. I never appreciated that, thanks. – SilverlightFox Mar 29 at 9:41
  • @SilverlightFox Thanks! – jub0bs Mar 29 at 10:48
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.

Improve this answer
3
  • Although if there's an XSS vulnerability, this could be used to read in a CSRF token first before the unsafe request. – SilverlightFox Feb 4 '16 at 11:54
  • Yes I overlooked that, thankyou. It would at the very least require a more involved XSS attack. – George Powell Feb 4 '16 at 12:20
  • XSS on a different origin that happens to be same-site is still a concern, as SameSite has no effect on cross-origin, same-site requests. – jub0bs Mar 27 at 12:44
0

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.

Improve this answer
2
  • As noted in v6 of the spec, the <link rel='prerender'> tag could still be used to invisibly load the target page. – SilverlightFox Feb 4 '16 at 11:57
  • @SilverlightFox: correct, but only when explicitly the non-default Lax mode is used. – Steffen Ullrich Feb 4 '16 at 12:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.