W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Isolated Web Components for a more secure web

From: Eduardo Robles Elvira <edulix@agoravoting.com>
Date: Sat, 28 Jun 2014 17:07:31 +0200
Message-ID: <CAHwZu3fZ3YkTBtYLxN4P1dJ07+6CtzJmUNaxx_PgtD_0xzTXBg@mail.gmail.com>
To: public-webappsec@w3.org
Hello people:

I'm Eduardo, developer of Agora Voting [0] among other things. I also
did some work on KHTML [1] some time ago, which is the topic I want to
address here, which as you can see I have been thinking about since
2009 [8].

Web Components rock - but we still need a way to make them more
secure. Imagine all these situations where you end up using an iframe,
creating a popup window or loading a different page just for security.
Here are two examples:

 * paypal: you might want to integrate paypal directly in your page,
but you can't do that because it's a security risk: the parent page
might be able to access to sensitive information or try to automatize
buying. That's why paypal loads in its own webpage or opens a popup.

 * twitter: you can embed a twitter widget in your web page, but the
twitter button (or reply/retweet) usually creates a small popup
window. Note that  for security, browsers don't allow you to access
DOM of an iframe/popup if it comes from another domain.

It's a problem of trust: there are certain things we cannot trust to
third party web sites when providing a service. We have do that in
isolation. What if we had a solution for this? The web would be much
more awesome than it currently is.

I'm also concerned in trusting that any website has not gone rogue:
maybe some evil government is doing a server-in-the-middle [1] and
changing the web-component that is doing a critical service to me.
This kind of thing has happened before [2] [3], and in a post-Snowden
era we cannot ignore that. Here are a couple of use cases:

 * When send an email or chatting with gmail, the messages are not
end-to-end encrypted, so you have to revert to desktop software or use
browser extensions [4].

 * Each time I vote online the new neighborhood community board with
AgoraVoting, I want to be able to trust that the web component I use
to vote has not been altered to modify my ballot so that John Doe wins
the election, and that it has not been modified to reveal the secrecy
of the vote.

 So here are some solutions that I propose to make "Isolated Web
Components" that address mentioned use-cases:

  * Isolate Web Components

    What: You can set properties to them, but that's it. When you use
an isolated web component in your page, you won't be able to modify or
access its contents in unpredictable ways. So no access to the shadow
root (::shadow, /deep/ or .shadowRoot would not work). Isolated
elements will also be final and not be extendable.

    Why: This will make web components secure. You will be able to
embed webcomponent in a third party website without having to trust
that website and without having to use an iframe/popup/etc.

    How: Add a boolean "isolated" to ElementRegistrationOptions [5] in
document.registerElement to activate the "isolated mode".

  * Subresource Integrity

    What: be able to specify digest for external resources to check
for integrity.

    Why: This way, as a website owner I can include a third party
resource whose code I trust in a specific version without risking that
it might change in any way that might compromise the security of my
whole web site.

    How: don't reinvent the wheel, just implement subresource
integrity spec [6] in the web browser.

  * Isolated Web Components browser padlock integration

    What: As a web browser user you'll be able to see what isolated
web-components are used in a page by clicking in the padlock in the
address bar. There you will see for example "paypal" for the <paypal>
element, and when you hover it with the mouse, it will be highlighted
where it is shown if it's a visible element. This list of web-elements
will also prominently show the domain where the element was defined.

    Why: This way an user will be able to easily spot if a page is
really using a legit web-component or it's fake. In the past, the only
way to do that is that the user sees the address of the webpage in the
address-bar (and the padlock for SSL).

    How: Adapt the web browser padlock to be more powerful and
informative, and propose this in the web security context user
interface guidelines [7]

  * Isolated Web Component Pinning

    What: Ceate some new HTTP Headers that will mark an isolated web
component loaded in that URL as pinned to that domain. When an enabled
web-browser loads that resource, it can show the user information
about the web component it's going to register. If a web page then
tries to use a web-component from the same domain from a different URL
and it's not pinned, it would fail.

    Why: This is something close to "installing plugins" in the web
browser *but it's not the same thing*. It's just a way to ensure that
if in a web site I use a pinned web-component, if someone hacks the
server or does a server-in-the-middle, creating maybe a new resource
in a different url (so that subresource integrity doesn't help) that
is loaded instead of the original web-component, at the very least,
the user will get some kind of warning that something has changed in
that web component.

    How: This would probably require a new specific specification. It
would work basically ceating a new set of HTTP Headers that will mark
an isolated web component loaded in that URL as pinned with a version.
Something like "Web-Component-Version: x.x.x" and
"Web-Component-Element: papal", "Web-Component-Allow-Pinning: true", maybe
"Web-Component-Description: Lorem ipsum lorem ipsum", etc. Or maybe,
we should do something similar to Google's "Certificate Transparency"
[9] for web components. Thing is, this is a problem we have to solve
somehow.

  * Isolated Web Components Origin tweak

    What: The web browser should use the origin of the domain in which
the isolated web component was defined, and not the domain in which
it's being shown.

    Why: This way web browsers will be able to continue enforcing the
same-origin security policy and requests will still only be able to be
done from code from the same-origin without having to use i.e. CORS to
allow requests from any domain, which is insecure.

    How: Specify in the standard [5] that isolated web components will
send the origin of the domain where they are defined.

This is just a wild proposal from someone which is just learning about
web-components and it's open to improvements, suggestions and
modifications. In any case I hope this post is a good start for the
conversation on how to address the security challenges that web
components might be able to solve.

Regards,
 --
 [0] https://agoravoting.com
 [1] http://edulix.wordpress.com/2012/01/08/the-server-in-the-middle-problem-and-solution/
 [2] https://en.wikipedia.org/wiki/Hushmail
 [3] https://en.wikipedia.org/wiki/Lavabit
 [4] http://googleonlinesecurity.blogspot.com.es/2014/06/making-end-to-end-encryption-easier-to.html
 [5] https://w3c.github.io/webcomponents/spec/custom/#dfn-document-registerElement
 [6] https://w3c.github.io/webappsec/specs/subresourceintegrity/
 [7] http://www.w3.org/TR/wsc-ui/
 [8] https://edulix.wordpress.com/2009/01/22/web-encryption-framework/
 [9] http://www.certificate-transparency.org/what-is-ct
Received on Monday, 30 June 2014 11:17:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC