On Nov 11, 2013, at 5:33 PM, Ryosuke Niwa <[email protected]> wrote: > On Nov 11, 2013, at 5:13 PM, Adam Barth <[email protected]> wrote: >> On Mon, Nov 11, 2013 at 12:57 AM, Ryosuke Niwa <[email protected]> wrote: >>> On Nov 11, 2013, at 3:56 PM, Adam Barth <[email protected]> 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? > > I intended to state this in point 6 but now I realize it wasn’t entirely > clear from the way I phrase it so let me elaborate a little more on this > point. > > When a cross-origin custom element is instantiated, the browser creates the > JS wrapper for the custom element in the context of the imported document. > It then creates a shadow root inside the imported document, attaches it to > the host element, and calls createdCallback with the shadow root. > > The custom element JS object is only visible inside the imported document. > It’s HTMLUnknownElement in the context of the host document although we’re > open to creating a proxy/fake element subclass which is not visible in the > global scope and identical to HTMLKnownElement in its prototype chain in the > host document as well.
Of course, the imported document will have a different script context (i.e. global object) than the host document. (Anne: Thank you for pointing this out). - R. Niwa
