[Greasemonkey] greasemonkey for secure data over insecure networks / sites

Aaron Boodman zboogs at gmail.com
Mon Jul 18 22:22:31 EDT 2005

I started writing this on the bus, and see that others have already
said it -- but I want to go ahead and send anyway.

> On a related note, the fact that xmlhttprequest doesn't exclude local
> file:// URL means that not only would placing this ability into a page
> allow a malicious attacker to read local files, but it also allows the
> GM script itself to read all local files.  This is still true for the
> sandbox approach Aaron is currently investigating, if the sandbox
> include chrome-privileged access to xmlhttprequest.
> How many people want to grant GM script writers access to their local
> harddrive when they install a GM script?

Agree, this was a mistake from the very beginning with
GM_xmlhttpRequest. I did not intend for it to grant access to the
local drive.

> My point is that scripts should be required to declare what privileges
> they need, and this must be enforced - either using Mozilla's security
> model or by implementing your own.

Again, I agree, in principle (no pun intended). Practically speaking,
there doesn't appear to be scriptable interfaces in mozilla to do what
you want me to. I don't have a huge problem implementing GM in C++,
but I don't have the tools to do that right now (a windows box with a
visual studio and a debug build of FF on it), and once I get that
solved, I expect it might take awhile to actually write the code.

So, I propose the sandbox approach. GM_xmlhttpRequest will verify that
URLs it accesses are http or https. I realize this may be brittle and
failure-prone, we'll have to do our best -- maybe mozilla provides
interfaces which can help normalize the URLs before we do the check.

Other than that, I don't believe we have a problem with any of the
other APIs, and we'll think about future APIs much more carefully.

The user script code itself will run in the content's security
principal, which is very low priv, the same context the site itself
runs in.

In a previous thread you asked some questions. I'll attempt to answer
them now, though I admit from the beginning that you know more about
this than me!

> Suppose the code contains
> addEventListener("someevent", function () { .... }, false)
> or
> setTimeout(10, function () { ... })
> In which security context will those functions execute?

As you said, it depends on the root of the stack. In both these cases,
user scripts don't have access to (namespace approach) any objects
which could exceute in a context other than content. Specifically it's
|window|setTimeout and |DOMNode|addEventListener. Both of those are in
the content's security context.

> Suppose the code contained:
> window.f = function () { ... }
> and some malicious code did window.f(), in which context would f() execute?

It depends on the origin of the malicious code's stack. If the
malicious code is in the content, it's the content's context. If the
malicious code is a user script, it's the content's context. If the
malicious code is a malicious FF extension or an exploit on FF itself,
we are hosed.


More information about the Greasemonkey mailing list