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
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.
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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,
22 matches
Mail list logo