456779 - Event.isTrusted should not be overwritten

Status: RESOLVED INVALID

(Core :: DOM: Events, defect)

Description

[John Resig]

Currently the isTrusted property of the event object is defined when a custom event is created. This allows a user to possibly overwrite that property (with a new getter) that will always return true - faking itself as being valid.

This doesn't appear to affect the browser itself (for example, link visiting is still not triggerable) but it does allow scripts to fake events, potentially causing malicious activity to occur (via extensions, Greasemonkey, or Ubiquity).

A sample snippet:

  var evt = document.createEvent("MouseEvents");
  evt.initMouseEvent("click", true, true, window, 0, 0, 
    0, 0, 0, false, false, false, false, 0, null);
  evt.__defineGetter__("isTrusted", function(){ return true; });
  link.dispatchEvent(evt);

See the URL for a full demo (click the button to trigger the result).

Comment 1

[John Resig]

As far as I see it there are two options:
 1) Disallow any attempts to overwrite or otherwise change the isTrusted getter on an event object or
 2) Set the isTrusted getter state to false inside dispatchEvent.

Comment 2

[John Resig]

After doing a quick search it appears as if there's a lot of instances in the
Mozilla source where it's blindly assumed that isTrusted is supposed to work as
advertised. This seems like a major concern:
http://mxr.mozilla.org/mozilla-central/search?string=isTrusted

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #1)
>  2) Set the isTrusted getter state to false inside dispatchEvent.
Some event listener could then set it true again.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Chrome gets safely wrapped event and uses native values, right?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

And in many cases those .isTrusted are useless in chrome.
By default chrome listens only trusted events and 
before calling those listeners event listener manager
uses the native event to check if event is trusted.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> By default chrome listens only trusted events

That's not true for XBL event handlers, afaik.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Though I suppose the for bug 265921 might have just been introducing unnecessary checks, given bug 265921 comment 4.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #4)
> Chrome gets safely wrapped event and uses native values, right?

Yeah. So a content-defined getter for isTrusted is invisible to chrome without exlicitly requesting it with wrappedJSObject.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #6)
> That's not true for XBL event handlers, afaik.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/xbl/src/nsXBLBinding.cpp&rev=1.262&mark=809,810,842-846,878-881#795
and
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/xbl/src/nsXBLEventHandler.cpp&rev=1.74&mark=143-145#125

Comment 10

[Brandon Sterne (:bsterne)]

Setting severity as low per comment 8.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #10)
> Setting severity as low per comment 8.
Why is this even low? What is the bug here?

Comment 12

[timeless]

smaug/brandon: can we try to decide if there's really no bug? :)

Comment 13

[Josh Aas]

Opening this up and marking invalid since smaug, timeless, and mrbkap were unable to identify an actual bug.