Security: Difference between revisions
see also with link |
No edit summary |
||
| (11 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
= | <div style="border: 3px dotted; color: red; font-size: 1.2em; padding: 0.5em; margin: 1em; text-align: center"> | ||
Warning: The contents of this page are not accurate in reference to Greasemonkey 4.0. | |||
</div> | |||
Historically, [[Greasemonkey]] would inject a [[user script]] into a page by creating a <code><script></code> tag with the [[user script]] contents inline, and appending it to the content page's DOM. | This page is a description of [[Greasemonkey]]'s security model. For tips you can apply directly to your scripts, see '''[[Security tips]]'''. | ||
== Overview == | |||
[[Version history|Historically]], [[Greasemonkey]] would inject a [[user script]] into a page by creating a <code><script></code> tag with the [[user script]] contents inline, and appending it to the content page's DOM. | |||
Mark Pilgrim originally [http://mozdev.org/pipermail/greasemonkey/2005-July/004022.html described a security flaw] with this design, on July 19th 2005, while [[Greasemonkey]] was at [[version]] 0.3.4. | Mark Pilgrim originally [http://mozdev.org/pipermail/greasemonkey/2005-July/004022.html described a security flaw] with this design, on July 19th 2005, while [[Greasemonkey]] was at [[version]] 0.3.4. | ||
Essentially, the issue was that Greasemonkey scripts are given special permissions that the rest of the javascript running on the web page is not. For example, Greasemonkey scripts contained their own GM_xmlhttprequest object which, unlike a normal xmlttprequest object, could access any local files one one's computer or make arbitrary requests to arbitrary sites without regard for the same origin policy that typically applies to xmlhttprequest. | |||
Unfortunately, because Greasemonkey scripts were injected directly into the page using a script tag, these objects with special permissions could be called by a script sent by the website. | |||
In other words, if you ran a Greasemonkey script on a site, the site's own javascript could access all the files on your computer! | |||
[[Greasemonkey]] [[version]] 0.3.5 was immediately released, with all [[API reference|GM_* functions]] disabled, to plug the security hole. | [[Greasemonkey]] [[version]] 0.3.5 was immediately released, with all [[API reference|GM_* functions]] disabled, to plug the security hole. | ||
To fix the security flaw, [[XPCNativeWrapper]]s, a new feature of the then-in-development Firefox 1.5, were used to isolate privileged [[user script]] code from insecure content pages. | To fix the security flaw, [[XPCNativeWrapper]]s, a new feature of the then-in-development Firefox 1.5, were used to isolate privileged [[user script]] code from insecure content pages. | ||
Certain other changes were made, including restrictions on the [[GM_xmlhttpRequest]] method, to disallow access to local files. | Certain other changes were made, including restrictions on the [[GM_xmlhttpRequest]] method, to disallow access to local files. | ||
= unsafeWindow = | == unsafeWindow == | ||
Wrapping the [[user script]] environment this way creates a [[sandbox]]. | Wrapping the [[user script]] environment this way creates a [[sandbox]]. | ||
This sandbox introduces many side effects and limitations. | This sandbox introduces many side effects and limitations. | ||
To allow maximum flexibility for [[user script]] authors, the <code>unsafeWindow</code> property was added in to the sandbox. | To allow maximum flexibility for [[user script]] authors, the <code>[[unsafeWindow]]</code> property was added in to the sandbox. | ||
The <code>window</code> object functions as the global scope in | The <code>window</code> object functions as the global scope in JavaScript. | ||
For [[user script]]s, this global window option is in fact a "deep wrapper" of the content window. | For [[user script]]s, this global window option is in fact a "deep wrapper" of the content window. | ||
The content window can be accessed by [[user script]]s, but only indirectly through the wrapper. | The content window can be accessed by [[user script]]s, but only indirectly through the wrapper. | ||
| Line 25: | Line 35: | ||
When a [[user script]] relies on the <code>unsafeWindow</code> property, it should be included only on trusted pages, and even then is not guaranteed to be safe. | When a [[user script]] relies on the <code>unsafeWindow</code> property, it should be included only on trusted pages, and even then is not guaranteed to be safe. | ||
= See Also = | == See Also == | ||
* [[Greasemonkey access violation]] | |||
* [[Greasemonkey Manual:Environment]] | |||
* [http://it.slashdot.org/article.pl?sid=05/07/19/143241 Slashdot: Firefox Greasemonkey Extension Security Problem] | * [http://it.slashdot.org/article.pl?sid=05/07/19/143241 Slashdot: Firefox Greasemonkey Extension Security Problem] | ||
{{stub}} | {{stub}} | ||
[[Category:Security|*]] | |||
Latest revision as of 20:02, 3 November 2017
Warning: The contents of this page are not accurate in reference to Greasemonkey 4.0.
This page is a description of Greasemonkey's security model. For tips you can apply directly to your scripts, see Security tips.
Overview
Historically, Greasemonkey would inject a user script into a page by creating a <script> tag with the user script contents inline, and appending it to the content page's DOM.
Mark Pilgrim originally described a security flaw with this design, on July 19th 2005, while Greasemonkey was at version 0.3.4. Essentially, the issue was that Greasemonkey scripts are given special permissions that the rest of the javascript running on the web page is not. For example, Greasemonkey scripts contained their own GM_xmlhttprequest object which, unlike a normal xmlttprequest object, could access any local files one one's computer or make arbitrary requests to arbitrary sites without regard for the same origin policy that typically applies to xmlhttprequest.
Unfortunately, because Greasemonkey scripts were injected directly into the page using a script tag, these objects with special permissions could be called by a script sent by the website. In other words, if you ran a Greasemonkey script on a site, the site's own javascript could access all the files on your computer!
Greasemonkey version 0.3.5 was immediately released, with all GM_* functions disabled, to plug the security hole.
To fix the security flaw, XPCNativeWrappers, a new feature of the then-in-development Firefox 1.5, were used to isolate privileged user script code from insecure content pages. Certain other changes were made, including restrictions on the GM_xmlhttpRequest method, to disallow access to local files.
unsafeWindow
Wrapping the user script environment this way creates a sandbox.
This sandbox introduces many side effects and limitations.
To allow maximum flexibility for user script authors, the unsafeWindow property was added in to the sandbox.
The window object functions as the global scope in JavaScript.
For user scripts, this global window option is in fact a "deep wrapper" of the content window.
The content window can be accessed by user scripts, but only indirectly through the wrapper.
The unsafeWindow property is a direct line to the actual content window.
Use of the unsafeWindow property should be avoided whenever possible.
Its use has the potential to open up all the original security holes that introducing the XPCNativeWrappers fixed.
When a user script relies on the unsafeWindow property, it should be included only on trusted pages, and even then is not guaranteed to be safe.
