UnsafeWindow: Difference between revisions

From GreaseSpot Wiki
Jump to navigationJump to search
m Text replace - "</pre>}}" to "</pre>"
remove nonsensical "syntax" section; 'page function' & 'attach script' section replaced with link to category with pages dedicated to the topic
Line 12: Line 12:
[[User script]] authors are '''strongly''' encouraged to learn how [[XPCNativeWrapper]]s work, and how to perform the desired function within their security context, instead of using unsafeWindow to break out.
[[User script]] authors are '''strongly''' encouraged to learn how [[XPCNativeWrapper]]s work, and how to perform the desired function within their security context, instead of using unsafeWindow to break out.


== Syntax ==
Compatibility: [[Version_history#0.5_beta|Greasemonkey 0.5b+]]


'''unsafeWindow'''
== Examples ==
 
:Value: Object
:Returns: Variant
:Compatibility: [[Version_history#0.5_beta|Greasemonkey 0.5b+]]


== Examples ==
<pre class='sample'>
<pre class='sample'>
unsafeWindow.SomeVarInPage = "Testing";
unsafeWindow.SomeVarInPage = "Testing";
Line 39: Line 34:
== Alternatives to unsafeWindow ==
== Alternatives to unsafeWindow ==


=== Events ===
''Sometimes'', you just can't get around using unsafeWindow.
 
Most of the time, however, you can!
Event listeners never need to be created on unsafeWindow. Rather than using
See [[:Category:Coding Tips:Interacting With The Page]] for details on various methods to interact with the page that do '''not''' use unsafeWindow.
<pre class='sample-bad'>unsafeWindow.onclick = function(event) { /* some code */ };</pre>
use:
<pre class='sample-good'>window.addEventListener("click", function(event) { /* some code */ }, false);</pre>
 
See also [https://developer.mozilla.org/en/DOM/element.addEventListener addEventListener at MDC].
 
=== Functions defined in the page ===
 
If a user script must execute a page function, it can use the '''[[location hack]]''' to call it safely. This involves setting location.href to a <code>javascript:</code> URL, which is like using a bookmarklet. For example:
 
{{Samp |why=WARNING: Cross-platform Location hack failure |1=<pre style="border: none; margin: inherit;">location.href = "javascript:void(pageFunc(123));";</pre>
 
Larger blocks of code independent of the Greasemonkey context/APIs can also be executed this way:
 
{{Samp |why=WARNING: Cross-platform Location hack failure |1=<pre style="border: none; margin: inherit;">location.href = "javascript:(" + function() {
  /*
    Some code here.
      Note that the Greasemonkey API is not directly accessible within this function.
  */
} + ")();";</pre>
or a more specific example:
 
{{Samp |why=WARNING: Cross-platform Location hack failure |1=<pre style="border: none; margin: inherit;">location.href = "javascript:(" + encodeURI(uneval(function() { /* some code */ })) + ")();";</pre>
 
This code will run in the page context without leaking the [[sandbox]]. This code is completely separate from the rest of the script scope, sometimes limiting its usefulness. For example, data cannot be returned by the function.
 
Another drawback is that this technique is rather ugly. Still, it is preferred over unsafeWindow.
 
=== Attach script to page ===
 
==== Attach Method 1 ====
<pre class='sample-good'>
function myScript() {
  for (var x in document) {
    /* some code with x */
  }
  /* some code */
}
 
/*
  Attaches script into page body and executes it via an anonymous function call.
    NOTES:
      Script can therefore reference variables on the page, but likewise cannot use Greasemonkey API methods
*/
 
var script = document.createElement("script");
script.type = "application/javascript";
script.textContent = "(" + myScript + ")();";
 
document.body.appendChild(script);
</pre>
 
==== Attach Method 2 ====
<pre class='sample-good'>
window.addEventListener(
  "DOMTitleChanged",
  function() {
    var redirectURL = window.name;
  },
  false
);
 
var sGetter = document.createElement("script");
sGetter.type = "application/javascript";
sGetter.textContent =
    "function uXHR(url) {"
  + "  var xhr = new XMLHttpRequest();"
  + "  xhr.onreadystatechange = function() { "
  + "    if (xhr.status == 301 || xhr.status == 302) {"
  + "      window.name = xhr.getResponseHeader('Location');"
  + "      document.title = document.title;"
  + "    }"
  + "  };"
  + "  xhr.open('HEAD', url, true);"
  + "  xhr.send(null);"
  + "}";
 
document.body.appendChild(sGetter);
 
unsafeWindow.uXHR(url);
</pre>
 
==== Attach Method 3 ====
Place this code at the very beginning of the script to inject the entire script into the page using the location hack. Like Attach Method 1, this will give the script access to variables on the page, but not access to Greasemonkey API methods.
{{Samp |why=WARNING: Cross-platform Location hack failure |1=<pre style="border: none; margin: inherit;">if (typeof window.wrappedJSObject == "object") {
  location.href = "javascript:(" + encodeURI(arguments.callee.toSource()) + ")();";
  return;
}
</pre>
'''Be very careful when using the wrappedJSObject property. It is just as dangerous as unsafeWindow is.'''


== Notes ==
== Notes ==


BUG: In Firefox 3.0 the <tt>prototype</tt> field will always be <tt>undefined</tt> for objects accessed through <tt>unsafeWindow</tt>. Attach method 1 can be used as a workaround for this problem.
BUG: In Firefox 3.0 the <tt>prototype</tt> field will always be <tt>undefined</tt> for objects accessed through <tt>unsafeWindow</tt>.
The techniques in [[:Category:Coding Tips:Interacting With The Page]] can work around this problem.


[[Category:API_Reference|U]]  
[[Category:API_Reference|U]]  
[[Category:Scripting context]]
[[Category:Scripting context]]
[[Category:Security]]
[[Category:Security]]

Revision as of 23:36, 8 February 2010

This command can open certain security holes in your user script, and it is recommended to use this command sparingly.

Please be sure to read the entire article and understand it before using it in a script.


Description

This API object allows a User script to access "custom" properties--variable and functions defined in the page--set by the web page. The unsafeWindow object is shorthand for window.wrappedJSObject. It is the raw window object inside the XPCNativeWrapper provided by the Greasemonkey sandbox.

  • USE OF UNSAFEWINDOW IS INSECURE, AND IT SHOULD BE AVOIDED WHENEVER POSSIBLE.

unsafeWindow bypasses Greasemonkey's XPCNativeWrapper-based security model, which exists to make sure that malicious web pages cannot alter objects in such a way as to make greasemonkey scripts (which execute with more privileges than ordinary JavaScript running in a web page) do things that their authors or users did not intend. User scripts should therefore avoid calling or in any other way depending on any properties on unsafeWindow - especally if if they are executed for arbitrary web pages, such as those with @include *, where the page authors may have subverted the environment in this way.

User script authors are strongly encouraged to learn how XPCNativeWrappers work, and how to perform the desired function within their security context, instead of using unsafeWindow to break out.

Compatibility: Greasemonkey 0.5b+

Examples

unsafeWindow.SomeVarInPage = "Testing";
unsafeWindow.SomeFunctionInPage("Test");
var oldFunction = unsafeWindow.SomeFunctionInPage;
unsafeWindow.SomeFunctionInPage = function(text) {
  alert('Hijacked! Argument was ' + text + '.');
  return oldFunction(text);
};

Alternatives to unsafeWindow

Sometimes, you just can't get around using unsafeWindow. Most of the time, however, you can! See Category:Coding Tips:Interacting With The Page for details on various methods to interact with the page that do not use unsafeWindow.

Notes

BUG: In Firefox 3.0 the prototype field will always be undefined for objects accessed through unsafeWindow. The techniques in Category:Coding Tips:Interacting With The Page can work around this problem.