Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A1 -> B -> A2 nested documents and cookies (and SameSite=None) #31

Open
annevk opened this issue May 18, 2022 · 2 comments
Open

A1 -> B -> A2 nested documents and cookies (and SameSite=None) #31

annevk opened this issue May 18, 2022 · 2 comments

Comments

@annevk
Copy link
Collaborator

annevk commented May 18, 2022

Assume a document nesting scenario of A1 -> B -> A2 whereby A1 and A2 are same-origin with each other and cross-site with B. In the real world this sometimes materializes as a publisher embedding an ad distributor that then decides to display an ad from the publisher.

As discussed in #25 and elsewhere it's generally considered good practice for A2 to be severed from A1 to avoid confused deputy attacks, which is why browsers are considering adding the "has cross-origin ancestors" bit to the partitioning key.

Now unlike other state, cookies have the unique ability to indicate these confused deputy attacks are defended against through the usage of SameSite=None. As such, the argument has been made that sending unpartitioned cookies to A2 is okay, as long as they use SameSite=None.

This creates some weirdness in that from a theoretical perspective B and A2 should not really be any different in terms of their relationship with A1. As in, both of them are partitioned. However, given the existing use cases and the unique ability of cookies to indicate confused deputy attacks were considered upon creation (to be clear, I somewhat doubt web developers consider that in detail, they also just want things to work) it might be acceptable to privilege A2.

Alternatives:

  • SameSite=None does not have special privileges that allow it to ignore the "has cross-origin ancestors" bit when setting the cookie. (This would be my personal preference as this kind of logic where we only look at part of the total key seems rather scary.)
  • We introduce another attribute specifically for these "has cross-origin ancestors" bit scenarios. I don't think there's enough benefit to the churn this ends up necessitating. SameSite=None already indicates a disregard for security.

(We discussed this scenario as part of privacycg/meetings#19.)

@johannhof
Copy link
Member

As mentioned in privacycg/meetings#19 (comment) we met about this at TPAC and there don't seem to be any concerns with continuing to send SameSite=None cookies in this scenario. Not sure if we want to continue tracking this issue until we're able to standardize the behavior or if we want to close it.

@johannhof
Copy link
Member

See caveat mentioned in privacycg/meetings#19 (comment) which means we may still want to discuss this with WebAppSec or similar security folks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants