Repository navigation
Script element mid-parse protection mechanism #525
Description
This issue is here to track the specific spec mechanism for protecting against a script that's edited mid-parse.
To avoid needing to look all over here's a summary. As of #499 all parsed scripts are trusted. The problem with this approach is that a script elements contents can be changed from JS before it finishes parsing. This is case tested by the first subtest of https://wpt.live/trusted-types/HTMLScriptElement-internal-slot.html and https://wpt.live/trusted-types/SVGScriptElement-internal-slot.html.
Chromium and WebKit's approach is to store a boolean flag on the HTML/SVGScriptElement which gets set to true, if the children of the script element are changed by an API. This flag is then checked before setting the script text data.
We cannot spec this directly due to the DOM specs children changed steps not providing the information as to whether something is changed by an API or parser. whatwg/dom#1288 - has been raised to discuss changes to the DOM spec which would be needed for this.
Activity
lukewarlow commentedon Jun 12, 2024
cc @mbrodesser-Igalia it would be good if you or someone else from mozilla could provide input on whether Gecko has a similar concept to WebKit and Chromium here. If they do then it makes the case for standardising this, and specifically this protection mechanism better.
smaug---- commentedon Jul 3, 2024
Gecko doesn't have such concept.
lukewarlow commentedon Jul 3, 2024
What would gecko do in this situation then? Do you know how gecko would protect from such a situation?
domfarolino commentedon Jul 23, 2024
So one scenario in which a parser-inserted script should be considered untrusted is when it edits itself mid-parse, which I think is what the document.write test case highlights that you pointed to. I think another scenario would be if a parser-inserted script that cannot immediately execute (maybe it has an invalid
typeattribute) has its children mutated via an API before itstypebecomes valid again. This is also a case that our special boolean flag (should we ever add one) would have to capture, right?(I guess I'm just trying to clarify whether the "mid-parse" part of the title of this issue is possibly too narrow, and is not the only case we need to consider)
lukewarlow commentedon Jul 24, 2024
I don't think a script can edit itself midparse?
#533 - here's my latest attempt at a model for this. Uses children changed steps always, and has some internal boolean flags. The main question I guess is does children changed ever get fired by the parser? If it doesn't then that PR should be good to go. I was under the impression it did, but I'm not so sure now.
THis should be covered by the existing system, and the new proposed one linked above.
Currently, it'll finish parsing, set the internal slot to the parsed value. It'll then have its child content changed but the slot not updated to match. By the time it gets to being executed the slot wont match reality and it'll be untrusted.
In the new proposed system, it'll finish parsing and be considered trusted. The children changed steps will be fired by the API change and that will set is trusted to false. By the time it gets to being executed the is trusted flag will be false.
lukewarlow commentedon Jul 25, 2024
So the first write intentionally leaves it open. As it then does appendChild as the "mid-parse manipulation". And then continues to document.write the close tag. document.write is covered by trusted types as many other parsing APIs. So I don't think this script protection model needs to worry about the contents of it much. It's more just being used as a mechanism for triggering the weird behaviour.