On Nov 11, 2013, at 3:56 PM, Adam Barth <w...@adambarth.com> wrote: > Can you help me understand what security properties your proposal > achieves and how it achieves them? I spent some time thinking about > this problem a couple of years ago when this issue was discussed in > depth, but I couldn't come up with a design that was simultaneously > useful and secure. > > For example, your proposal seems to have the vulnerability described below: > > == Trusted container document == > > <link rel="import" > href="https://untrusted.org/untrusted-components.html" > importcomponents="name-card"> > <body> > <name-card ></name-card> > > == untrusted-components.html == > > <template defines="name-card" interface="NameCardElement"> > Name: {{name}}<br>Email:{{email}} > </template> > <script> > NameCardElement.prototype.created = function (shadowRoot) { > var victim = shadowRoot.ownerDocument; > var script = victim.createElement("script"); > script.textContent = "alert(/hacked/);"; > victim.body.appendChild(script); > }; > </script> > > Maybe I'm not understanding your proposal correct? If this issue is > indeed a vulnerability with your proposal, I have no doubt that you > can modify your proposal to patch this hole, but iterating in that way > isn't likely to lead to a secure design.
The owner document of the shadow root in that case will be that of the component; i.e. https://untrusted.org/untrusted-components.html in this case. In other words, we’re inserting a security boundary between the host element and the shadow root. The shadow root in this case is a funky node object in that it has its host element in an entirely different document. - R. Niwa