On Wed, Aug 09, 2017 at 07:18:44AM -0600, Eric H. Jung wrote:
> On Wed, Aug 9, 2017 at 3:36 AM, Richard Z <r...@linux-m68k.org> wrote:
> > On Tue, Aug 08, 2017 at 10:46:24PM -0600, Eric H. Jung wrote:
> > > >
> > > >
> > > > Isn't this a security disaster waiting to happen analogous to this:
> > > >   https://bugzilla.mozilla.org/show_bug.cgi?id=1287590
> > > >
> > > > Has this been somehow addressed?
> > > >
> > >
> > > That bug is about iframes. No one in this thread has suggested that you
> > > inject an iframe into web content. I believe you can inject non-iframe
> > HTML
> > > and not be subject to the security implications in that bug.
> >
> > how do you come to this conclusion? On the contrary: the "hostile" webpage
> > into which you inject your div has unlimitted access to your injected
> > content
> > Add a nice password input field to your div and the javascript of the
> > webpage
> > gets the password for free.
> >
> This is a different kind of attack as described in the bug, at least the
> parts of the bug that I read.

of course it extends to everything ever injected into a webpage. If a "div"
would magically protect you, then all you need to do is hide your iframe
in a div - right? I am surprised nobody mentioned this simple solution
in the bug report. And yes, the original issue on github was filled by me.

> > The situation is slightly better with an injected iframe because the
> > hostile
> > webpage can not directly access it. However it can do any number of tricks
> > like overlaying it (z-index), reading out its visible content by canvass
> > ops,
> > replacing it with own iframe so in practice the only difference is that the
> > hostile webpage has it slightly more difficult to determine what you are
> > displaying.
> >
> This is a different kind of attack as described in the bug, at least the
> parts of the bug that I read.
> I believe the same attack you describe is also possible if using a browser
> action popup. This supposed webpage could overly the exact same size div
> where your addon's popup should display, although it cannot do it in
> response to your click on the browser action icon click. Watching mouse
> movement off-page to the 0 coordination of the x-axis would be a good
> substitute, and if the popup looks like the addon's popup, the user might
> think he simply clicked by accident.

If a webpage can overlay a native popup of Firefox than we have a really
very huge problem. Have about overlaying that master password entry field?
But luckilly, native browser popups are somewhat privileged so this *should*
not happen. What can happen is a very good immitation of the popup though.

> The aforementioned bug was about iframes, although I did not read the
> entire bug. I thought it's risk was about getting web-page source injected
> back into the addon. That's not what you're describing here and not what
> you originally discussed.

as said before, anything injected into a potentialy hostile webpage is under
(concurrent) control of that webpage.


Name and OpenPGP keys available from pgp key servers

mobile-firefox-dev mailing list

Reply via email to