Security tips
From GreaseSpot
Contents |
[edit] Mind your includes
Make sure your script does not accidentally execute on pages besides its intended includes. Some scripts have includes like these:
// @include http://www.example.com* // @include http://www.example.* // @include http://*example.com/*
These can match pages that accidentally or maliciously have similar URLs. Consider these examples:
- http://www.example.com.evil.int/steal-info.html
- http://evil-example.com/steal-info.html
As the example URLs hint, the danger is that stored GM_getValues or configuration variables (that potentially contain personal information such as passwords) are exposed to malicious sites. Even with non-malicious sites and scripts that don't deal in personal information, having scripts apply to the wrong site can cause unexpected behavior or JavaScript errors.
Always start your include with http:// or https://, followed by the full domain name you want to match, followed by a slash. A common error is to match http*://... as a shortcut for both http and https versions of a site, but this can be exploited by malicious pages with URLs such as http://evil.example.com/here-comes-the-colon-slash-slash://match-the-rest-of-the-include....
The magic syntax // @include http://www.example.tld/* will match a domain name under any top-level domain. This is better than matching example.*, but still potentially exploitable.
If the include syntax is not robust enough to match a particular URL pattern, a more lenient match will do as long as the rest of the script is preceded by something along the lines of:
if (/goo+gle/.test(location.href)) {
// user script code
}
or, equivalently (since Greasemonkey executes scripts wrapped in a function):
if (! /goo+gle/.test(location.href)) return; // user script code
In general, it is best to ask, "What other URLs could potentially match my include?". If the answer is not "none", either make sure it is completely safe to run the script for arbitrary pages, change the include rules, add an exclude rule, or add additional tests within the code.
[edit] Use data:URIs, not remote resources
If a script needs e.g. custom graphics, it is advisable to include them in the script as data: URIs (using for example the data: URI Image Encoder) rather than host them on your own server.
Remote resources essentially means the browsing history of any user of the script is tracked in the server access logs, especially so if the script applies to all URLs and if the resource is unique to the script.
Another reason for using data:URIs is that the script will not have a dependency on a remote resource that is subject to server uptime.
Using the resources of a site you're scripting against (e.g. Google) is usually fine, since you're accessing that site anyway. But if every Google visit means a request to http://example.com/greasemonkey/reload.png, then the example.com access logs could potentially be used to trace your Google history.
