SameSite Cookies and Iframes

[devd]

If I have a website that I want to allow framing by trusted third-parties (via CSP frame-ancestors), I can't use SameSite cookies to prevent CSRF attacks. This is unfortunate as it limits adoption of samesite cookies as the standard mechanism to protect against CSRF attacks. I have run into multiple projects where I can't use same site cookies due to this issue.

I would love a flag that tells the user agent to treat requests from framed pages as same site.

[johnwilander]

Not that I like the proliferation of cookies, but can’t you set both SameSite and non-SameSite cookies and then make the decision server-side what to allow in the framed and the non-framed cases? You’re in control of which sites can frame you through CSP.

In the case of Safari (default settings), such framing across sites will lead to classification of the domain as having cross-site tracking abilities and thus its cookies will be blocked in third-party contexts. CSRF is then automatically prohibited since the frame needs to call the Storage Access API to get cookie access.

[devd]

So, I don't fully understand the Safari setup, but I believe once the Storage access API is requested, the app will still need CSRF protections within the frame, right? I.e., once the user grants permission, it will be very similar to what happens by default in Chrome?

Re your point in the first paragraph: that's exactly what I want. The problem is: how do you figure out whats coming from your own page when framed vs an actual CSRF attempt from a third party page? Right now, there is no way to do that in a Samesite cookie world. If instead, I put in 2 cookies biscotti and macaron that are both same site but the macaron cookie is sent even in iframes then when my server gets a request, these decisions are easy. Here's the three settings:

1. biscotti and macaron exist: a same site request when top level page is same site
2. biscotti does not exist but macaron exists: a same site request but page is iframed
3. both biscotti and macaron don't exist: CSRF attempt.

Right now, note that what the server sees on number 2 and number 3 above is the same.

[johnwilander]

In Safari’s implementation of the Storage Access API you need user interaction in the frame per page. New page with CSRF attack => no cookies. Different iframe with CSRF attack => no cookies. We would like this to become the default way to allow a cross-site iframe to authenticate the user.

I’m a little rusty on the Origin header. Won’t it be there in the requests you want to accept? That combined with CSP control of which sites can frame you should suffice.

For further protection you have the Cross Origin Resource Policy response header.

[devd]

Yeah.. I am talking about how the page can protect itself after user interaction and authorization for 3rd party cookie use. Unfortunately, the origin header isn't reliable for csrf protections. Also, do you have a reference for the cross origin resource policy header for csrf defense? I don't think I understand that.

…

On Sun, Jan 27, 2019, 9:00 PM John Wilander ***@***.*** wrote: In Safari’s implementation of the Storage Access API you need user interaction in the frame per page. New page with CSRF attack => no cookies. Different iframe with CSRF attack => no cookies. We would like this to become the default way to allow a cross-site iframe to authenticate the user. I’m a little rusty on the Origin header. Won’t it be there in the requests you want to accept? That combined with CSP control of which sites can frame you should suffice. For further protection you have the Cross Origin Resource Policy response header. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#762 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIXGXYAT-zwkHoBDwvUnQiyu4SQ7Griks5vHoP8gaJpZM4aU2WG> .

[johnwilander]

Do you mean the case where your iframe successfully gets storage access and then a CSRF attack happens from the same iframe? Or the CSRF attack calls the Storage Access API?

CORP doesn’t help with traditional CSRF, but if you worry about CSRF+Spectre attacks reading your users’ content, it does help.

[devd]

yup .. iframe gets storage access and now wants to hit CSRF protected endpoints. I can't use samesite cookies; I have to do some of the other options (e.g., csrf tokens in session cookie) for csrf defense

…

On Sun, 27 Jan 2019 at 22:03, John Wilander ***@***.***> wrote: Do you mean the case where your iframe successfully gets storage access and then a CSRF attack happens from the same iframe? Or the CSRF attack calls the Storage Access API? CORP doesn’t help with traditional CSRF, but if you worry about CSRF+Spectre attacks reading your users’ content, it does help. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#762 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIXGQOoR-Ul7aQvBOgUoD1oTLY8gvkiks5vHpKpgaJpZM4aU2WG> .

[pmhsfelix]

Any further information regarding this issue? I believe I've the exact same problem as @devd.
I'm using two cookies:

• A _regular cookie with session data.
• A SameSite marker cookie, without any data, that is used only to detect if the request is cross-site or not (some cross-site requests are still allowed to access session data).
  However, a request sent from an iframe hosted on a different site never sends the SameSite cookie, even after user interaction and a Set-Cookie inside the frame .
  If I understood it correctly, this is the behaviour defined on https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.2.1, however it makes it impossible to distinguish a same-site request inside an iframe from a real cross-site request.
  So, if I'm not missing something, this makes the SameSite mechanism useless for CRSF protection if usage inside frames is required.

[aghassemi]

@mikewest @johnwilander @rowan-m
I believe this is an important use-case that deserves consideration or at least some public documentation on best practices on how to handle in. (even despite the fact that Safari has broken iframe-based version of this use-case by default regardless of SameSite, other approaches such as querying authenticated 3P endpoints via fetch are still applicable in this discussion)

Authenticated embedibility is a common use-case (YouTube, social widgets, etc..), but currently there is no option to protect auth cookies from CSRF via SameSite (the main intended value provided by this feature) without breaking authenticated embedibility.

Has there been discussions on additional values that are more lax than lax? Something along the lines of none-get-strict-post where all GET requests behave as if none is set but all POST requests follow as if strict.

[ibolmo]

@aghassemi @devd @johnwilander has there been any breakthroughs here. I'm running into the same scenario.

[johnwilander]

These kind of discussions should take obsoletion of third-party cookies into account. We don’t know details of Chrome’s plans but we know the plan is to obsolete them by January 2022.

[som-nitjsr]

I am also facing the same issue.
i have site with samesite=strict cookie now i wanted to host this site it in another domain with iframe
i have set the Content-Security-Policy: frame-ancestors 'self' , other domain. but iframe is not sending the samesite cookie back to server

[annevk]

I think John's comment above is on point given that cross-site cookies are planned to be blocked eventually by all browsers. So this can be closed as WONTFIX, unless the area of interest is cookies for A2 in A1 -> B -> A2. Is it?