Location hack: Difference between revisions

From GreaseSpot Wiki
Jump to navigationJump to search
(wrote initial text. will fill in remaining sections later)
 
(filled in undone sections. destubbed)
Line 28: Line 28:


== Executing large blocks of code ==
== Executing large blocks of code ==
Executing more than one statement can become unreadable very easily. Luckily, Javascript can convert functions to strings, so you can use:
location.href = "javascript:(" + function() {
  // do something
} + ")()";
Even though the function is defined in the sandbox, it is not a closure of the sandbox scope. It is converted to a string and then back to a function in page scope. It cannot access anything in the sandbox scope, which is a limitation, but is also essential to making this technique secure.


== Returning values ==
== Returning values ==


{{stub}}
Functions called through the location hack cannot return data directly to the user script scope. To communicate between location hack code and regular user script code, data must be placed where the user script can see it, for example, by writing it into the DOM, or by triggering an event. A simple example:
 
var oldBodyTitle = document.body.title;
location.href = "javascript:void(document.body.title = pageFunc())";
var fauxReturnValue = document.body.title;
document.body.title = oldBodyTitle;

Revision as of 19:02, 15 March 2007

The location hack is an ugly but useful way to interact with the content scope of the page being user scripted.

Background

For security reasons, Greasemonkey uses XPCNativeWrappers and sandbox to isolate it from the web page. Under this system, the user script can access and manipulate the page using event listeners, the DOM API, and GM_* functions.

Sometimes the sandbox is too limiting, in which case the user script can access other parts of the page using unsafeWindow. As the name unsafeWindow implies, this can often be unsafe, and expose security holes.

In December 2005, Jesse Ruderman came up with the location hack, to be an alternative to unsafeWindow in many cases.

Basic usage: page functions

Suppose the page contains a function called pageFunc, or window.pageFunc. The user script knows this function as unsafeWindow.pageFunc.

The user script could simply call unsafeWindow.pageFunc(), but this can leak the sandbox. Instead, the user script can take advantage of javascript: URLs, which always run in the content scope. Just entering this URL into the browser's location bar does not leak a Greasemonkey sandbox:

javascript:void(pageFunc())

Similarly, a user script can set location.href to this URL to safely call the function:

location.href = "javascript:void(pageFunc())";

Modifying the page

The location hack can do anything a page script or bookmarklet can do, so it can modify content variables and such as easily as it can access them. For example:

location.href = "javascript:void(window.someVariable = 'someValue')";

Executing large blocks of code

Executing more than one statement can become unreadable very easily. Luckily, Javascript can convert functions to strings, so you can use:

location.href = "javascript:(" + function() {
  // do something
} + ")()";

Even though the function is defined in the sandbox, it is not a closure of the sandbox scope. It is converted to a string and then back to a function in page scope. It cannot access anything in the sandbox scope, which is a limitation, but is also essential to making this technique secure.

Returning values

Functions called through the location hack cannot return data directly to the user script scope. To communicate between location hack code and regular user script code, data must be placed where the user script can see it, for example, by writing it into the DOM, or by triggering an event. A simple example:

var oldBodyTitle = document.body.title;
location.href = "javascript:void(document.body.title = pageFunc())";
var fauxReturnValue = document.body.title;
document.body.title = oldBodyTitle;