- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 9 Apr 2012 23:48:27 +0000 (UTC)
On Mon, 9 Apr 2012, Jonas Sicking wrote: > > It seems clear to me that there is a use-case for sending a message to > your parent frame, but only wanting to do so when your parent frame is > from the same origin as you. That use case is already behind handled by ancestorOrigins, see the recent thread with Adam. WebKit is working on an experimental implementation. We're also going to expose the page's own origin; currently that's specced in Adam's URL spec but I expect that to be added to the HTML spec in due course. (I believe Adam posted about that recently too.) On Mon, 9 Apr 2012, Tyler Close wrote: > > The RPH handler doesn't need to know which is the legit site. The RPH > handler just needs to know that it's getting the RPH data from the site > that the user was interacting with, not some other unseen site running > in the browser. Nothing we have discussed so far would provide such a guarantee. Indeed, I don't see how we _could_ provide such a guarantee. In the case you describe, the "legit" site framing the handler could just as easily spawn the handler via a scripted navigation as it could do so by waiting for the user to click the mailto: link. > Putting the %s data in the window.location lets an attacker overwrite > it. Only if it is in the fragment identifier. I whole-heartedly agree that it shouldn't be in the fragment identifier (it doesn't have to be -- if your mail client works offline using long-lasting cache headers, it's even easier to make it work using appcache). Assuming we merge the logic for the various register*Handler()s with Web Intents as I recently proposed, we also provide a way for the information to be accessible to a scripted handler, regardless of where the information is placed in the URLs. > >> The important thing to understand here is that a communication > >> channel that is vulnerable to tampering can be abused in unexpected > >> ways. > > > > You don't need to tamper with the communications channel as far as I > > can tell. If you can navigate an <iframe> as you describe, then even > > if the mailto: information is put in the path or query component it > > would still be possible to do the attack you describe. Just wait for > > the iframe to appear and then navigate it to the mailto: handler with > > the parameters you want. > > That's exactly right! The whole window.location communication path is > vulnerable to tampering, so we need some other way to communicate the > RPH %s data, such as a DOM field. Honestly, I'm not really sure why you would use an iframe at all here. I certainly wouldn't trust a site that framed GMail and expected me to send e-mail that way. If they want me to send an e-mail, then let my mail client open in the top-level browsing context (ideally the current one, but failing that a new tab). > With appcache fallback, it's not necessary to use only the URL fragment > for an offline scenario to work, which makes talking about the URL > fragment in this scenario extraneous. Assuming the mailto RPH handler is > using appcache with a fallback, this whole scenario works if the %s data > is in the path or query. The problem is that the whole window.location > is a communication channel that is vulnerable to tampering within the > browser. As far as I can tell, this is false. (The HTML spec is not especially good about describing the reality here, unfortunately.) > The vulnerability is that window.location can be overwritten by other > code running in the browser. Then we should fix _that_. This has nothing to do with register*Handler(). If window.location can be overritten cross-origin, then half the Web is broken -- e.g. GMail is full of iframes. If you could overwrite them with custom iframes at will, then spoofing would be trivial. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 9 April 2012 16:48:27 UTC