On Mon, Nov 11, 2013 at 12:57 AM, Ryosuke Niwa <rn...@apple.com> wrote: > 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.
Was that written somewhere in your proposal and I missed it? Adam
