- From: Greg Billock <gbillock@google.com>
- Date: Wed, 14 Dec 2011 13:55:05 -0800
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
Received on Wednesday, 14 December 2011 13:55:05 UTC