Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Tyler Close
On Sat, Apr 7, 2012 at 10:17 AM, Ian Hickson i...@hixie.ch wrote: In the case of window.open, it's true that the opener could have navigated by the time you try to communicate back. That's a general problem with window.open(), though; it's not specific to register*Handler(). The solution

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Jonas Sicking
Why is this so complicated? 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. There appears to be to ways of doing so right now: 1. Hardcoding the origin as a literal 2.

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Tyler Close
On Mon, Apr 9, 2012 at 3:12 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Apr 2012, Tyler Close wrote: The user sends the email, confirming the attacker's operation, instead of their own. From the user's perspective, they see that they are at the legitimate web site and they setup an

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Tyler Close
On Mon, Apr 9, 2012 at 4:23 PM, Tyler Close tyler.cl...@gmail.com wrote: On Mon, Apr 9, 2012 at 3:12 PM, Ian Hickson i...@hixie.ch wrote: Just wait for the iframe to appear and then navigate it to the mailto: handler with the parameters you want. That attacker has to navigate the iframe to

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Tyler Close
On Mon, Apr 9, 2012 at 4:17 PM, Jonas Sicking jo...@sicking.cc wrote: Why is this so complicated? 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. I think there's also a

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Ian Hickson
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

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Tyler Close
On Mon, Apr 9, 2012 at 4:48 PM, Ian Hickson i...@hixie.ch wrote: 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

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-09 Thread Ian Hickson
On Mon, 9 Apr 2012, Tyler Close wrote: On Mon, Apr 9, 2012 at 4:48 PM, Ian Hickson i...@hixie.ch wrote: 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

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-07 Thread Ian Hickson
On Fri, 6 Apr 2012, Tyler Close wrote: On Fri, Apr 6, 2012 at 3:36 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 6 Apr 2012, Tyler Close wrote: Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. What happens if the handler sends the

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-06 Thread Tyler Close
On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: I was recently experimenting with the registerProtocolHandler (RPH) API and came across a couple of security gotchas that make it hard to safely use the API. One of these is already known,

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-06 Thread Ian Hickson
On Fri, 6 Apr 2012, Tyler Close wrote: On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: I was recently experimenting with the registerProtocolHandler (RPH) API and came across a couple of security gotchas that make it hard to

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-06 Thread Tyler Close
On Fri, Apr 6, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 6 Apr 2012, Tyler Close wrote: On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: I was recently experimenting with the registerProtocolHandler (RPH) API and

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-06 Thread Ian Hickson
On Fri, 6 Apr 2012, Tyler Close wrote: Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. What happens if the handler sends the postMessage to *, then the parent is navigated? Will the postMessage be delivered or not? A task queued on a

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-06 Thread Tyler Close
On Fri, Apr 6, 2012 at 3:36 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 6 Apr 2012, Tyler Close wrote: Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. What happens if the handler sends the postMessage to *, then the parent is

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-06 Thread Tyler Close
On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: For example, a web mail program might have two registered RPH handlers for mailto: https://example.org/?from=me@companyq=%s; and https://example.org/?from=me@personalq=%s;. The user has

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-02 Thread Ian Hickson
On Mon, 26 Sep 2011, Tyler Close wrote: I was recently experimenting with the registerProtocolHandler (RPH) API and came across a couple of security gotchas that make it hard to safely use the API. One of these is already known, but AFAICT, hasn't been fixed yet. I haven't seen the other

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-02 Thread Boris Zbarsky
On 4/2/12 7:39 PM, Ian Hickson wrote: For example, an attacker could open a window on a victim web page. The victim web page then opens aniframe on a content URL that triggers RPH. The attacker then navigates theiframe so that its window.location contains a different content URL. How can the

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2012-04-02 Thread Ian Hickson
On Mon, 2 Apr 2012, Boris Zbarsky wrote: On 4/2/12 7:39 PM, Ian Hickson wrote: For example, an attacker could open a window on a victim web page. The victim web page then opens aniframe on a content URL that triggers RPH. The attacker then navigates theiframe so that its

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2011-09-27 Thread Jonas Sicking
On Mon, Sep 26, 2011 at 11:48 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/26/11 2:09 PM, Tyler Close wrote: I suggest fixing this problem by adding a new readonly DOMString that contains the correct origin for the postMessage invocation; perhaps document.origin. I would be somewhat in

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2011-09-27 Thread Tyler Close
On Mon, Sep 26, 2011 at 11:09 AM, Tyler Close tyler.cl...@gmail.com wrote: The second problem with RPH is that the handler page doesn't have a way of reliably getting the URL of the content to be handled from the browser. In order to work in offline scenarios, the RPH handler must put the %s

[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2011-09-26 Thread Tyler Close
I was recently experimenting with the registerProtocolHandler (RPH) API and came across a couple of security gotchas that make it hard to safely use the API. One of these is already known, but AFAICT, hasn't been fixed yet. I haven't seen the other discussed yet. The Mozilla blog post that

Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler

2011-09-26 Thread Boris Zbarsky
On 9/26/11 2:09 PM, Tyler Close wrote: AFAICT, there is no API that the intent handler can reliably use to determine the correct targetOrigin for this postMessage invocation. That's correct, though as long as you don't use too much in the way of about:blank or javascript: or data: URIs,