You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider recording the "duplicate-attribute" error state. #3257
CSP attempts to defend against some kinds of dangling-markup attacks by preventing the execution of scripts that include "<script" in an attribute name or value. Discarding attributes during parsing makes it possible to trivially work around this defense, as described in https://crbug.com/740615. As dropping repeated attributes is also the root cause of the dangling-markup risk in the first place, it might be reasonable to dig into it a little more deeply to see if something more fundamental can be done.
Unfortunately this is still a pretty big hole in nonce based CSP policies because it opens very simple avenues for injection points to become dangling-markup nonce-stealing attacks.
Does the above approach detailed by Mike seem reasonable. What are peoples thoughts?
To me this seems like a good idea given the potential threats, though it definitely adds some complexity (given the need to propagate the error). That said, my opinion probably shouldn't for a huge amount here. 🙂
Propagating a "this script is questionable enough that it should not run" bit to the DOM is doable from the parser perspective. Gecko already does this for scripts that were truncated by early EOF.
Let's not overdo it, though. Let's make it just one bit that says the there was at least one duplicate attribute without trying to retain knowledge of which attribute was duplicated and how all the way through the stack. Or even just one bit saying the script isn't eligible to run (in case we want to add other reasons later or combine it right away with the truncation-by-early-EOF case).
Activity
Elements with duplicated attributes are not nonceable.
annevk commentedon Nov 27, 2017
cc @whatwg/html-parser
bzbarsky commentedon Nov 28, 2017
@hsivonen
andypaicu commentedon Nov 9, 2018
Unfortunately this is still a pretty big hole in
noncebased CSP policies because it opens very simple avenues for injection points to become dangling-markup nonce-stealing attacks.Does the above approach detailed by Mike seem reasonable. What are peoples thoughts?
gsnedders commentedon Nov 9, 2018
To me this seems like a good idea given the potential threats, though it definitely adds some complexity (given the need to propagate the error). That said, my opinion probably shouldn't for a huge amount here. 🙂
hsivonen commentedon Nov 12, 2018
Propagating a "this script is questionable enough that it should not run" bit to the DOM is doable from the parser perspective. Gecko already does this for scripts that were truncated by early EOF.
Let's not overdo it, though. Let's make it just one bit that says the there was at least one duplicate attribute without trying to retain knowledge of which attribute was duplicated and how all the way through the stack. Or even just one bit saying the script isn't eligible to run (in case we want to add other reasons later or combine it right away with the truncation-by-early-EOF case).
Reland of "CSP: Block nonces for elements with duplicate attributes."
andypaicu commentedon Dec 5, 2018
I've raised the 2 referenced PR's, please have a look and let me know what you think.
Elements with duplicated attributes are not nonceable.
evilpie commentedon Jan 26, 2024
This is still a problem, that I discovered while implementing the nonceable check in Firefox.