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. Richard -- Name and OpenPGP keys available from pgp key servers _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
