-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Added a duplicate attribute present member to element create call #4223
base: main
Are you sure you want to change the base?
Conversation
dom PR: whatwg/dom#721 |
@annevk Hi Anne, could I bother you to look at this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this approach is much more general than the issue suggested we needed. Instead of passing it off to "create an element", could we not use it if that ends up creating a script element? And then set one of the existing bits on the script element (perhaps renaming it to make more sense)?
d77b1e8
to
654efb4
Compare
I'm now setting it after constructing the element as you suggested. I'm not entirely sure if there's any reason to only set it on |
The travis CI is failing because I now am referencing |
I'd rather only modify What's the reason to expose it on all elements if you can only observe it for |
This is news to me. What is this internal slot and where is documented? Or are we talking here about implementations already having this slot?
Well currently none really, but in the future I imagine all sorts of elements might be whitelisteable via nonces and we will probably need to have the same safeguards. |
I assumed the slot discussed in #3257 (comment) was standardized. I'm not entirely sure it is though, but it seems this could also be done with "ready to be parser-executed". |
Hmm in what way could this be done with
I take it that changes to DOM are to be avoided if possible so perhaps a new flag similar to |
Yeah, I think I'd prefer not generalizing until the need is concrete. Also, I didn't realize it was still somewhat dynamic, in that it depends on a CSP check, in which case I agree that it needs to be a new flag of sorts. |
I've updated this PR and closed the DOM PR. |
There is a test for the duplicate attribute vulnerability: And I represent implementer interest from the side of Chrome. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good modulo nits, thanks!
Thank you @annevk I've addressed the nits |
Thanks for driving the editorial work over the finish line. Couple other things to address before we can land this. Hope that's understandable. Is the CSP logic yet to be written? Although maybe it's already written given there's non-tentative tests? How does that work? Mike indicated this was discussed at TPAC, but the minutes weren't detailed enough around this particular item to discern interest from others. I'm willing to accept Henri's analysis though as meaning Mozilla would eventually adopt this. We'll need bugs against Firefox and Safari. |
The CSP logic needs to be reworded to use this flag. Currently it is written around the The nonce hijacking consideration section also mentions this again with an issue raised. (https://w3c.github.io/webappsec-csp/#dangling-markup-attacks) I should be able to spin a PR pretty quick if it's needed before this PR lands but I obviously can't land that PR in CSP before this one lands. The reason we have the test is because it was identified as a security vulnerability and we wanted to get it patched asap in Chrome. This is currently already implemented in Chrome (version 72 which I think is just now getting to beta). I am happy to raise bugs against Firefox and Safari. Should I raise them now or wait until this PR is part of the spec? |
You can raise those now. And let's do the CSP cleanup PR also now (and just rerun the build after this lands) for completeness as that's what we typically do to make sure a new primitive actually meets the needs of consumers. I'll probably land this tomorrow then unless someone else gets to it first. |
@@ -57856,6 +57856,12 @@ o............A....e | |||
<span data-x="prepare a script">prepared</span>, based on the <code | |||
data-x="attr-script-src">src</code> attribute of the element at that time.</p> | |||
|
|||
<p>The seventh is a flag indicating whether or not the script has a <dfn | |||
data-x="concept-script-duplicate-attribute">duplicate attribute</dfn>. This flag is intially |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks to the CSP PR I realized we need to export this. You'll need to add: data-export="" data-dfn-type="dfn" data-dfn-for="script"
to the <dfn>
.
@andypaicu did this ship in Chrome, should this still be standardized? |
This flag is needed for both |
Issue: #3257
Added a flag to set during tokenizer parsing step if a duplicate attribute is found.
Changed the
create an element
call to pass this new flag.💥 Error: Wattsi server error 💥
PR Preview failed to build. (Last tried on Jan 15, 2021, 7:58 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.