- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 11 Nov 2013 16:57:43 +0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>
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.
- R. Niwa
Received on Monday, 11 November 2013 08:58:24 UTC