search

httpwg / http-extensions

HTTP Extensions in progress
https://httpwg.org/http-extensions/
444 stars 146 forks source link

SameSite Cookies and Iframes #762

Open devd opened 5 years ago

devd commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 <notifications@github.com 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 https://github.com/httpwg/http-extensions/issues/762#issuecomment-457999561, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIXGXYAT-zwkHoBDwvUnQiyu4SQ7Griks5vHoP8gaJpZM4aU2WG .

johnwilander commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 https://github.com/httpwg/http-extensions/issues/762#issuecomment-458008216, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIXGQOoR-Ul7aQvBOgUoD1oTLY8gvkiks5vHpKpgaJpZM4aU2WG .

pmhsfelix commented 5 years ago

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

aghassemi commented 5 years ago

@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 commented 4 years ago

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

johnwilander commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

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?