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

Portals and SameSite policy #182

Open
piochu opened this issue Apr 26, 2020 · 1 comment
Open

Portals and SameSite policy #182

piochu opened this issue Apr 26, 2020 · 1 comment
Labels
design work needed An acknowledged gap in the proposal that needs design work to resolve

Comments

@piochu
Copy link

piochu commented Apr 26, 2020

As it states in RFC6265, if SameSite flag is set to Lax "the cookie will be sent with same-site requests, and with cross-site top-level navigations". A top-level navigation in context of portals occurs when portal is activated. However just after portal is attached to the DOM (when portal is not yet activated) there is no top-level navigation (guest browsing context; URL in browser does not change). In such case cookie with SameSite flag set to Lax should not be sent in cross-site request, but is sent (tested in Chrome 81.0.4044.113 stable and 84.0.4122.3 canary). In my opinion this should be considered as violation of SameSite policy.

I'm aware that portals are defined as "a new kind of top-level browsing context [...]", however top-level browsing context is something else that top-level browsing navigation.

In sample attack scenario I can attach/inject a portal element e.g. with display:none style and user will not have a chance to notice, that cross-site request with his cookies has been sent.

Reproduction steps

  1. For domain A set cookie with SameSite flag "Lax":
document.cookie = 'test=123;path=/;max-age=3600;SameSite=Lax'
  1. In context of domain B execute following code:
portal = document.createElement('portal');
portal.src = '//A/';
document.body.appendChild(portal);
  1. Check if created cookie was attached to the request.
    Result: cookie is attached.
    Excepted result: cookie should not be attached.

Recommendation
This is tricky issue for sure, but I believe that step no. 10 from section "To set the source URL of a portal element element, run the following steps" should be extended witch one more check, whether new request is same-site or cross-site. Based on the result of this check, a decision must be made as to whether or not a cookie protected by SameSite should be attached.

@jakearchibald
Copy link
Collaborator

The current feeling is that cross-origin portals will have no access to storage while portaled, but can be granted storage when they're activated. There's some trickiness around this of course #184

@domenic domenic added the design work needed An acknowledged gap in the proposal that needs design work to resolve label May 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design work needed An acknowledged gap in the proposal that needs design work to resolve
Projects
None yet
Development

No branches or pull requests

3 participants