Change declarative Shadow DOM fragment parsing to be opt-in #26398
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpt-pr-bot
approved these changes
Nov 4, 2020
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2513525
branch
2 times, most recently
from
5914328
to
df5cbac
Compare
This CL implements most of the suggestions from [1], which effectively block declarative Shadow DOM from being used by any fragment parser entry point, unless an explicit opt-in is toggled. The opt-ins include: - DOMParser.allowDeclarativeShadowDom = true; - HTMLTemplateElement.allowDeclarativeShadowDom = true; - XMLHttpRequest.allowDeclarativeShadowDom = true; - DocumentFragment.allowDeclarativeShadowDom = true; - Document.allowDeclarativeShadowDom = true; // For innerHTML - A new <iframe> sandbox flag: allow-declarative-shadow-dom This mitigates the potential client-side XSS sanitizer bypass detailed in the explainer and at [1]. Assuming these changes are functional, and mitigate the issue, this new behavior will be folded into the spec PRs at [2] and [3]. But given the security implications of the existing code, I'd like to get this landed first. [1] whatwg/dom#912 (comment) [2] whatwg/html#5465 [3] whatwg/dom#892 Bug: 1042130 Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525 Commit-Queue: Mason Freed <masonfreed@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Cr-Commit-Position: refs/heads/master@{#824591}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2513525
branch
from
df5cbac
to
6f8f99d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.
The opt-ins include:
This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.
[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892
Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#824591}