illicitonion · April 19, 2012 14:28
diff --git a/gistfile1.txt b/gistfile1.txt
 Allow privileged extension contexts to cross origin boundaries.

 Problem:
 Before Firefox 8, extensions could manipulate any subframe through chromeWindow.getBrowser().contentWindow.frames[0].frameElement regardless of cross-origin status.
 There are valid uses for this capability; any extension which manipulates content, password managers, etc. should reasonably expect to be able to manipulate iframes.
 My motivating example usage is for browser automation for the purposes of test, where on the selenium/webdriver project has a bug reported which has picked up >40 followers in five months [putting it in the top 1.5% of bugs by popularity, where the top bugs have been open for several years].  Link to bug for reference: https://code.google.com/p/selenium/issues/detail?id=2863

 Note that extensions have privilege to open new windows at arbitrary sites, and perform arbitrary manipulations on the pages, so preventing the manipulation of iframes in this way does not provide any obvious security benefit, other than reducing the potential surface of bugs in implementation.  Extensions can also currently break out of this restriction, in the process introducing vulnerabilities, as described in Workarounds.

 Workarounds:
 An extension can currently force access to cross-origin frames with the following code snippet:

 var Cc = Components.classes;
 var Ci = Components.interfaces;
 var prefManager = Cc['@mozilla.org/preferences-service;1'].getService(Ci.nsIPrefBranch);
 prefManager.setCharPref('capability.policy.default.Window.QueryInterface', 'allAccess');
 prefManager.setCharPref('capability.policy.default.Window.frameElement.get', 'allAccess');

 However, this removes cross-frame security policies for the whole browser, not just the extension, opening up attacks from untrusted code.  Also, from a testing perspective, this removes the ability to test for cross-origin frame access bugs.

 The list of whitelisted methods in the code snippet is unlikely to be complete, and so this workaround, while opening up vulnerabilities, may also not entirely solve the problem - the worst of both worlds.

 Proposals (alternatives):
 1) Treat extension contexts as trusted parts of every domain, allowing extensions to access that frame.
 2) Add a frozen-to-extensions preference to enable 1)
 3) Add a command line flag to enable 1).


 Example extension showing the problem:
 http://illicitonion.com/2863/crossdomainframe.xpi
 Note: This is a new-style extension; in old-style extensions you can just set preferences in-line and this solves the problem, I haven't gotten this working in a new-style extension, but I assume that's because of my inexperience and ineptitude with new-style extensions.
	Allow privileged extension contexts to cross origin boundaries.

	Problem:
	Before Firefox 8, extensions could manipulate any subframe through chromeWindow.getBrowser().contentWindow.frames[0].frameElement regardless of cross-origin status.
	There are valid uses for this capability; any extension which manipulates content, password managers, etc. should reasonably expect to be able to manipulate iframes.
	My motivating example usage is for browser automation for the purposes of test, where on the selenium/webdriver project has a bug reported which has picked up >40 followers in five months [putting it in the top 1.5% of bugs by popularity, where the top bugs have been open for several years]. Link to bug for reference: https://code.google.com/p/selenium/issues/detail?id=2863

	Note that extensions have privilege to open new windows at arbitrary sites, and perform arbitrary manipulations on the pages, so preventing the manipulation of iframes in this way does not provide any obvious security benefit, other than reducing the potential surface of bugs in implementation. Extensions can also currently break out of this restriction, in the process introducing vulnerabilities, as described in Workarounds.

	Workarounds:
	An extension can currently force access to cross-origin frames with the following code snippet:

	var Cc = Components.classes;
	var Ci = Components.interfaces;
	var prefManager = Cc['@mozilla.org/preferences-service;1'].getService(Ci.nsIPrefBranch);
	prefManager.setCharPref('capability.policy.default.Window.QueryInterface', 'allAccess');
	prefManager.setCharPref('capability.policy.default.Window.frameElement.get', 'allAccess');

	However, this removes cross-frame security policies for the whole browser, not just the extension, opening up attacks from untrusted code. Also, from a testing perspective, this removes the ability to test for cross-origin frame access bugs.

	The list of whitelisted methods in the code snippet is unlikely to be complete, and so this workaround, while opening up vulnerabilities, may also not entirely solve the problem - the worst of both worlds.

	Proposals (alternatives):
	1) Treat extension contexts as trusted parts of every domain, allowing extensions to access that frame.
	2) Add a frozen-to-extensions preference to enable 1)
	3) Add a command line flag to enable 1).


	Example extension showing the problem:
	http://illicitonion.com/2863/crossdomainframe.xpi
	Note: This is a new-style extension; in old-style extensions you can just set preferences in-line and this solves the problem, I haven't gotten this working in a new-style extension, but I assume that's because of my inexperience and ineptitude with new-style extensions.
No results found