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.

Sign up for GitHub

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

Jump to bottom

Sandbox, COOP, and error pages. #7345

Closed
hemeryar opened this issue Nov 18, 2021 · 4 comments
Closed

Sandbox, COOP, and error pages. #7345

hemeryar opened this issue Nov 18, 2021 · 4 comments
Labels
topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header topic: sandbox

Comments

@hemeryar
Copy link
Member

hemeryar commented Nov 18, 2021 •
edited
Loading

When a sandboxed iframe, tries to opens a popup to a COOP page, we return an error page in the popup instead. This is specified here:

If browsingContext is a top-level browsing context, then:

  • Set responseCOOP to the result of obtaining a cross-origin opener policy given response and request's reserved client.

  • If sandboxFlags is not empty and responseCOOP's value is not "unsafe-none", then set response to an appropriate network error and break.

In particular this assumes that keeping a handle to the popup with the error page is safe. However a recent bug shows that this surface is sufficient to leak information. Should we maybe consider cutting the opener if we end up in this case?

Note, for this to work:

  • The sandboxed iframe must have allow-popups
  • The sandboxed iframe must not have allow-popups-to-escape-sandbox, otherwise the popup does not have a sandbox flag
  • The sandboxed iframe must not have a top-level frame that sets COOP, otherwise because it's cross-origin the popup gets noopener automatically.
@annevk annevk added topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header topic: sandbox labels Nov 18, 2021
@annevk
Copy link
Member

annevk commented Nov 18, 2021

So:

  1. Create new top-level browsing context A.
  2. Replace A with B, which causes A to close.
  3. Navigate B to a network error.

User agents could alternatively do:

  1. Create a new top-level browsing context A. (Perhaps not visible to the user.)
  2. Close A.

I think that would be reasonable.

@hemeryar
Copy link
Member Author

Updated the original post with implicit assumptions.

To make sure I understand your proposals, we have option 1:

  • Open the popup on about:blank, with inherited sandbox flags, and opaque origin.
  • Start the navigation to a page, wait for the response, it ends up being a page with COOP. Go through with the navigation, COOP BC group swap happens, opener gets removed.
  • Once the page loaded, load an error page.

Or Option 2:

  • Open the popup on about:blank, with inherited sandbox flags, and opaque origin. but don't show it.
  • Start the navigation to a page, wait for the response, it ends up being a page with COOP, close the popup.

I discussed with @ArthurSonzogni, and I think we prefer option 1, as keeping the popup not visible when we open from a sandboxed iframe until we have a first navigation sounds confusing to the user and is probably hard to implement as well.

As for practically implementing option 1 in the spec, I don't think we want to restart the navigation to an error page, but we could simply enforce COOP even in this case. I'm thinking we could just move

  • If sandboxFlags is not empty and responseCOOP's value is not "unsafe-none", then set response to an appropriate network error and break.

after

  • Set coopEnforcementResult to the result of enforcing the response's cross-origin opener policy given browsingContext, request's URL, responseOrigin, responseCOOP, coopEnforcementResult and request's referrer.

@annevk
Copy link
Member

annevk commented Nov 19, 2021

I wasn't viewing them as different proposals; they are implementation alternatives as they should be indistinguishable as far as web pages are concerned. Your proposal for the HTML standard makes sense. I agree that we wouldn't want to wait for the COOP document to load.

I was wondering if instead of checking responseCOOP we should be checking coopEnforcementResult's needs a browsing context group switch, but that might result in different behavior. In particular if you have sandboxed A (but with allow-same-origin) opening A and both have COOP, I suspect coopEnforcementResult's needs a browsing context group switch would be false.

@hemeryar
Copy link
Member Author

Indeed relying on coopEnforcementResult might open other holes in the sandbox rule that we probably don't want.

@hemeryar hemeryar mentioned this issue Nov 24, 2021
Merged
3 tasks
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 24, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
a7b195e 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior. We set the COOP value before
the Sandbox + COOP failure to have access to it in the policy container.
We update the policy container inheritance for error pages, to take into
account COOP if it was set. That breaks the invariant of having all
error pages use "unsafe-none".

We only want error pages to sever their opener (and do things implied by
COOP), we never want them to end up in cross-origin isolated contexts.
We add an exception to the centralized computation of
WebExposedIsolationInfo to exclude error pages. They are never
considered cross-origin isolated.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 24, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
4ea3089 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior. We set the COOP value before
the Sandbox + COOP failure to have access to it in the policy container.
We update the policy container inheritance for error pages, to take into
account COOP if it was set. That breaks the invariant of having all
error pages use "unsafe-none".

We only want error pages to sever their opener (and do things implied by
COOP), we never want them to end up in cross-origin isolated contexts.
We add an exception to the centralized computation of
WebExposedIsolationInfo to exclude error pages. They are never
considered cross-origin isolated.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
@camillelamy camillelamy mentioned this issue Nov 26, 2021
Closed
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 26, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
7cc42ed 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 29, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
f5fa6aa 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 29, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
6a86a43 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 29, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
1dbe459 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 29, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
d758127 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 29, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
fca8feb 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 30, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
f424f8f 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 30, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
a2fad34 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3293412
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 30, 2021
@hemeryar @chromium-wpt-export-bot
[Fixit] Make sandbox + COOP break the opener.
4401bb5 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3293412
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}
@annevk annevk closed this as completed in c7d7a4c Nov 30, 2021
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Nov 30, 2021
@hemeryar
[Fixit] Make sandbox + COOP break the opener.
d400fcf 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3293412
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Dec 1, 2021
@hemeryar @moz-wptsync-bot
Bug 1742815 [wpt PR 31731] - [Fixit] Make sandbox + COOP break the op…
7b4147e 
…ener., a=testonly

Automatic update from web-platform-tests
[Fixit] Make sandbox + COOP break the opener.

Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3293412
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}

--

wpt-commits: 4401bb56f90668983f6c237523a85f8875be9c77
wpt-pr: 31731
aosmond pushed a commit to aosmond/gecko that referenced this issue Dec 1, 2021
@hemeryar @moz-wptsync-bot
Bug 1742815 [wpt PR 31731] - [Fixit] Make sandbox + COOP break the op…
251e3e9 
…ener., a=testonly

Automatic update from web-platform-tests
[Fixit] Make sandbox + COOP break the opener.

Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3293412
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}

--

wpt-commits: 4401bb56f90668983f6c237523a85f8875be9c77
wpt-pr: 31731
qtprojectorg pushed a commit to qt/qtwebengine-chromium that referenced this issue Feb 12, 2022
@hemeryar @mibrunin
[Backport] CVE-2022-0461: Policy bypass in COOP
6f9e52b 
Manual cherry-pick of patch originally reviewed on
https://chromium-review.googlesource.com/c/chromium/src/+/3293412:
[Fixit] Make sandbox + COOP break the opener.

Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
qtprojectorg pushed a commit to qt/qtwebengine-chromium that referenced this issue Feb 18, 2022
@hemeryar @mibrunin
[Backport] CVE-2022-0461: Policy bypass in COOP
2ef6d67 
Manual backport of patch originally reviewed on
https://chromium-review.googlesource.com/c/chromium/src/+/3293412:
[Fixit] Make sandbox + COOP break the opener.

Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
qtprojectorg pushed a commit to qt/qtwebengine-chromium that referenced this issue Mar 3, 2022
@hemeryar @mibrunin
[Backport] CVE-2022-0461: Policy bypass in COOP
f32d1db 
Manual backport of patch originally reviewed on
https://chromium-review.googlesource.com/c/chromium/src/+/3293412:
[Fixit] Make sandbox + COOP break the opener.

Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
@hemeryar @mfreed7
Enforce COOP first when opening a popup from a sandbox
b23d9fa 
I.e., the relationship between the browsing contexts is severed first and only then does the popup become a network error.

Tests: WPT html/cross-origin-opener-policy/coop-sandbox-cuts-opener.https.html.

Closes whatwg#7345.
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@hemeryar @copybara-github
[Fixit] Make sandbox + COOP break the opener.
29ee5ef 
Sandbox flags and COOP cannot currently live on the same page. This was
decided when first implementing COOP. If COOP and sandboxing flags are
present on the same top level window, we return an error page instead,
and COOP has no effect.

Exploits have been discovered recently about abusing an opened window
and history to be able to guess the cross-origin url using the history
API. See:
https://bugs.chromium.org/p/chromium/issues/detail?id=1208614

Error pages were left out from the fix, because it would be inelegant
to insert error pages into history after a successful reload. That means
error pages can potentially be used to guess a cross-origin URL.

If in general this is acceptable, in our case its worse for two reasons:
- COOP is used to protect pages that are usually more valuable or hold
  important data.
- It is possible to reach an error page after response without relying
  on timing, etc.

Therefore we'd like to sever the opener when we fail after receiving a
response, if the target page did set COOP. Basically we'd like to change
the spec to enforce COOP even when we fail because of COOP+sandbox.

Spec discussion can be found here:
whatwg/html#7345

On the implementation side, this patch adds the WPTs necessary to the
spec change, and the modified behavior.

We add a setter to the swap parameter to be able to only activate that
without breaking the COOP: Unsafe-none for error pages invariant. This
applies to final responses and redirects.

This does not alter the reload behavior, as this only happens for cases
where reloads would not be successful anyway.

Bug: 1256823
Change-Id: Ic79623a2b752608bc46a031d1f567308441d42e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3293412
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946387}
NOKEYCHECK=True
GitOrigin-RevId: d400fcfcccd5d1fc636d8758fcfa3c9490f37ca5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header topic: sandbox
Milestone
No milestone
Development

No branches or pull requests
2 participants
@annevk @hemeryar