[whatwg] Proposal: <intent> tag for Web Intents API

[Greg Billock]

Simon Pieters wrote:

> I'm not sure it's a good idea security-wise to have this feature as an
> element. Many sites use black-list based HTML filtering of user input, to
> filter out "bad" stuff like <script> elements. It's easy to argue that
> they are already screwed, but we still have to think about it when adding
> new features to the platform, because there are many such sites. It would
> be easy to inject an <intent> tag to such sites, whereas it is harder to
> call navigator.register*Handler.

It's true that if a site is relying on tag stripping, it might be
easier to inject an
<intent> tag than raw script content. (On the other hand, it seems that such a
site is likely to have other vulnerabilities...) But there's still another big
hurdle between that injection and an attack. (The user must approve the
registration, then perform an action which launches the intent, then select the
service, but let's say those are much smaller hurdles.) Even with
malicious content
chosen by the attacker, the only impact on the target page is
injecting a "window.intent"
object with some opaque (but malicious!) content. Getting the page to execute
that malicious content is the big hurdle. Either you can inject code
into the page
causing this execution, in which case, why bother, or the page is using
window.intent unsafely. This is a concern, but in that case, the
exploit is more easily
accomplished directly, rather than a circuitous route through an
injected <intent> tag.

Another threat model related to this is cross-origin registration. If
an <intent> tag can
be injected with a cross-origin service, information about the current
page state could be
leaked to the malicious host by way of that cross-origin url. If the
site is relying on a
blacklist (so, say, <img> tags couldn't be injected), and has a
vulnerability allowing
the gathering of information on the page or the DOM context, then an
<intent> tag
injection is a new vehicle to carry that data to an attacker. Again,
there's a couple more
obstacles: the user would need to approve the registration and then
launch an intent, but
those sound easy to arrange. The real way to combat this is to not
allow cross-origin
service registration.


> Separately, I'm not so happy with having two APIs for the same thing. We
> don't enable anything new, but we double the attack surface, the cost to
> implement and test, authors need to not only learn both, but also need to
> learn (and argue) about which to use, and so forth. register*Handler has
> already been shipped in some browsers.

We've seen some down-sides of the imperative registration approach:
clients ask for
ways to detect if they are registered, which breaks opacity and is, I
think, a bigger
security concern than the above. A declarative registration places the
burden for
maintaining that opacity on the user agent, which is a more
appropriate place for
such burdens. :-)

-Greg Billock