- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 11 Nov 2013 17:40:43 +0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>
- Message-id: <B3D3DC83-7AA5-4BDD-97BC-771A6E8907CA@apple.com>
On Nov 11, 2013, at 5:33 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> On Nov 11, 2013, at 5:13 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Nov 11, 2013 at 12:57 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>> On Nov 11, 2013, at 3:56 PM, Adam Barth <w3c@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?
>
> 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
Received on Monday, 11 November 2013 09:41:13 UTC