Any plan to support Event.isTrusted attribute in Chrome?

[James Su]

Hi,

  One of my colleague is trying to fix a XSS security issue in a chrome extension, which needs to distinguish if a keyboard or mouse event is actually fired by the user. Seems that Event.isTrusted attribute fits the requirement perfectly, but unfortunately Chrome doesn't support it. So we are wondering if there is any plan to support it in Chrome in near future? Or is there an alternate way to achieve it?

Thanks a lot.

--
- James Su

[Ron Waldon]

I didn't think it was possible for JavaScript to simulate keyboard events (to prevent impersonation of the user).

[James Su]

(Repost with correct account)
It's possible to fake keyboard/mouse events to manipulate dom nodes and make the scripts listening the events believe that they are the users intention.

2014年1月10日 上午9:15于 "Ron Waldon" <jokey...@gmail.com>写道：

I didn't think it was possible for JavaScript to simulate keyboard events (to prevent impersonation of the user).

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Adam Barth]

We don't implement isTrusted on purpose because it's not possible to implement in a meaningful way.  A script can just add a fake "isTrusted" property to events it creates.

Adam

--

[James Su]

So is there an alternative way to tell if an event is faked or real?
And isn't isTrust readonly? How can it be overridden? How is it implemented in firefox?

[Adam Barth]

There is no way to tell whether an event is real or fake.  There isn't any distinction between real and fake events.  Events are just events.

Adam

[Brett Wilson]

Mozilla bug with patch is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=637248

Looks like they have some special hardcoded magic for methods called
isTrusted().

Brett

[James Su]

Looks interesting, can we do the same thing in chrome?
The mozilla patch looks not very complicated.

[Paweł Hajdan, Jr.]

It looks it's even less hardcoded that it seems from your e-mail - apparently they already had support for [Unforgeable] before that patch.

--- a/dom/webidl/Event.webidl
+++ b/dom/webidl/Event.webidl
@@ -25,16 +25,17 @@ interface Event {
   void stopPropagation();
   void stopImmediatePropagation();
 
   readonly attribute boolean bubbles;
   readonly attribute boolean cancelable;
   void preventDefault();
   readonly attribute boolean defaultPrevented;
 
+  [Unforgeable]
   readonly attribute boolean isTrusted;
   readonly attribute DOMTimeStamp timeStamp;
 
   [Throws]
   void initEvent(DOMString type, boolean bubbles, boolean cancelable);
 };
 
 // Mozilla specific legacy stuff.

[Daniel Bratell]

On Fri, 10 Jan 2014 06:19:09 +0100, Adam Barth <aba...@chromium.org> wrote:

> There is no way to tell whether an event is real or fake. There isn't
> any distinction between real >and fake events. Events are just events.

There is a difference between user initiated/created events and script
created events though, and that distinction can be interesting to scripts
(it's certainly very interesting to C++ code looking at events).

And assuming browsers/users/pages don't inject malicious scripts into
themselves, they can trust the Event.isTrusted attribute.

/Daniel

[PhistucK]

Yes, but they had to change the binding generator in order to support that for Event for some reason.

(I am still advocating for this feature, of course)

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[PhistucK]

Say a native application creates an keydown event and sends it to the browser. Can a browser tell whether the event is fake?

Does the operating system provides the means for that somehow?

Actually, I keep thinking about use cases, but I reject any use case I find. No matter the level at which the verification lies, a mouse click can still be forged, whether by virtual or physical means, for example.

It can be forged using JavaScript (if the isTrusted event is not implemented).

It can be forged using a native application (if the answer to the above question is no).

It can be forged using a specially crafted mouse/USB/whatever driver (I guess).

It can be forged using an actual, physical mouse clicking machine.

Event.isTrusted can provide a very basic defence mechanism for the simple case (the first and maybe also the second scenarios above, depending on the answer to the question above).

Perhaps this provides enough functionality to justify its inclusion, though, since we probably mainly care about the innocent user or newbie hacker use cases.

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:   http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Bernhard Bauer]

If you control all the code yourself (i.e. nothing gets injected), couldn't you just do the opposite and set an isSynthesized flag on synthesized events? If code does get injected, there's really not much you can do -- the code runs in the same execution context (assuming an XSS like the original email said), and it's indistinguishable from the "real" code.

Bernhard.

 

/Daniel

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:   http://groups.google.com/a/chromium.org/group/chromium-dev

[James Su]

The real scenario is that a website containing malicious code may control the code injected by a chrome extension (a virtual keyboard in the original case) by faking mouse events to achieve some unexpected goals, e.g. click the virtual keyboard drawn by the extension to input malicious content into an iframe with a page from another website. It's possible because the extension injects code into both outside and nested pages, and the virtual keyboard is drawn on the outside page. It's perfect legal if the user clicks the virtual keyboard to input something into the nested page. But it'll be dangerous if a malicious script in the outside page can do the same thing by faking events. So the virtual keyboard extension surely want to avoid such thing by only accept trusted mouse events.

[Bernhard Bauer]

Is that actually possible (i.e. do you have a reproduction case for it)? AFAIU, a web page can't fire event handlers that an extension defined (or the other way around), because they have different JS execution contexts (see https://developer.chrome.com/extensions/content_scripts.html#execution-environment).

Bernhard.

Bernhard.

[PhistucK]

Events are DOM based and the DOM is shared, so, I believe both of world get the events.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Torne (Richard Coles)]

On 10 January 2014 12:20, James Su <su...@chromium.org> wrote:

The real scenario is that a website containing malicious code may control the code injected by a chrome extension (a virtual keyboard in the original case) by faking mouse events to achieve some unexpected goals, e.g. click the virtual keyboard drawn by the extension to input malicious content into an iframe with a page from another website. It's possible because the extension injects code into both outside and nested pages, and the virtual keyboard is drawn on the outside page. It's perfect legal if the user clicks the virtual keyboard to input something into the nested page. But it'll be dangerous if a malicious script in the outside page can do the same thing by faking events. So the virtual keyboard extension surely want to avoid such thing by only accept trusted mouse events.

From this description it sounds like the virtual keyboard is being added to the *page's* DOM by the extension. Am I understanding correctly?

If so, then this is insecure anyway, no? If the threat is "the web page contains malicious JS which wants to force a certain sequence of virtual keyboard clicks", then it seems like you can achieve this without generating any "fake" click events at all just by manipulating the DOM something like this:

1) Find the DOM node corresponding to the virtual keyboard key you want to be clicked next

2) Make a visual duplicate of it to leave in place

3) Make the original DOM node invisible in some way

4) Reposition that node so that it's always right underneath the user's mouse cursor as it moves

Now whenever the user clicks on something on the page, they'll click on the virtual keyboard and type something into your iframe. You can add your own onclick handler to the same DOM node and then have *that* handler inject a fake click event on whatever was underneath at that point on the page, so the user doesn't wonder why their clicks aren't doing anything. If you want a plausible reason for the user to click on your page content a lot without navigating away, just make your malicious page a match-three game. :)

It just seems like there's no way for anything inside the page's DOM to ever be secure against the page being malicious. If an extension wants to provide a virtual keyboard securely this would have to be somewhere *outside* the page's DOM (e.g. in a separate window, or extension popup, or whatever)

 

2014年1月10日 下午7:42于 "Bernhard Bauer" <bau...@chromium.org>写道：

On Fri, Jan 10, 2014 at 11:12 AM, Daniel Bratell <bra...@opera.com> wrote:

On Fri, 10 Jan 2014 06:19:09 +0100, Adam Barth <aba...@chromium.org> wrote:

There is no way to tell whether an event is real or fake.  There isn't any distinction between real >and fake events.  Events are just events.

There is a difference between user initiated/created events and script created events though, and that distinction can be interesting to scripts (it's certainly very interesting to C++ code looking at events).

And assuming browsers/users/pages don't inject malicious scripts into themselves, they can trust the Event.isTrusted attribute.

If you control all the code yourself (i.e. nothing gets injected), couldn't you just do the opposite and set an isSynthesized flag on synthesized events? If code does get injected, there's really not much you can do -- the code runs in the same execution context (assuming an XSS like the original email said), and it's indistinguishable from the "real" code.

Bernhard.

 

/Daniel

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:   http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[James Su]

2014年1月10日 下午11:20于 "Torne (Richard Coles)" <to...@chromium.org>写道：
>
> On 10 January 2014 12:20, James Su <su...@chromium.org> wrote:
>>
>> The real scenario is that a website containing malicious code may control the code injected by a chrome extension (a virtual keyboard in the original case) by faking mouse events to achieve some unexpected goals, e.g. click the virtual keyboard drawn by the extension to input malicious content into an iframe with a page from another website. It's possible because the extension injects code into both outside and nested pages, and the virtual keyboard is drawn on the outside page. It's perfect legal if the user clicks the virtual keyboard to input something into the nested page. But it'll be dangerous if a malicious script in the outside page can do the same thing by faking events. So the virtual keyboard extension surely want to avoid such thing by only accept trusted mouse events.
>
> From this description it sounds like the virtual keyboard is being added to the *page's* DOM by the extension. Am I understanding correctly?
>
> If so, then this is insecure anyway, no? If the threat is "the web page contains malicious JS which wants to force a certain sequence of virtual keyboard clicks", then it seems like you can achieve this without generating any "fake" click events at all just by manipulating the DOM something like this:
>
> 1) Find the DOM node corresponding to the virtual keyboard key you want to be clicked next
> 2) Make a visual duplicate of it to leave in place
> 3) Make the original DOM node invisible in some way
> 4) Reposition that node so that it's always right underneath the user's mouse cursor as it moves
>

Interesting idea, but can't the extension avoid it by chrcking the DOM node's positiion and visibility from time to time?

> Now whenever the user clicks on something on the page, they'll click on the virtual keyboard and type something into your iframe. You can add your own onclick handler to the same DOM node and then have *that* handler inject a fake click event on whatever was underneath at that point on the page, so the user doesn't wonder why their clicks aren't doing anything. If you want a plausible reason for the user to click on your page content a lot without navigating away, just make your malicious page a match-three game. :)
>
> It just seems like there's no way for anything inside the page's DOM to ever be secure against the page being malicious. If an extension wants to provide a virtual keyboard securely this would have to be somewhere *outside* the page's DOM (e.g. in a separate window, or extension popup, or whatever)

It's not practical on chrome, because AFAIU, it's not possible for an extension to show a separate window without stealing the keyboard focus. Please let me know if there is a way to do it.

>  
>>
>> 2014年1月10日 下午7:42于 "Bernhard Bauer" <bau...@chromium.org>写道：
>>
>>> On Fri, Jan 10, 2014 at 11:12 AM, Daniel Bratell <bra...@opera.com> wrote:
>>>>
>>>> On Fri, 10 Jan 2014 06:19:09 +0100, Adam Barth <aba...@chromium.org> wrote:
>>>>
>>>>> There is no way to tell whether an event is real or fake.  There isn't any distinction between real >and fake events.  Events are just events.
>>>>
>>>>
>>>> There is a difference between user initiated/created events and script created events though, and that distinction can be interesting to scripts (it's certainly very interesting to C++ code looking at events).
>>>>
>>>> And assuming browsers/users/pages don't inject malicious scripts into themselves, they can trust the Event.isTrusted attribute.
>>>
>>>
>>> If you control all the code yourself (i.e. nothing gets injected), couldn't you just do the opposite and set an isSynthesized flag on synthesized events? If code does get injected, there's really not much you can do -- the code runs in the same execution context (assuming an XSS like the original email said), and it's indistinguishable from the "real" code.
>>> Bernhard.
>>>  
>>>>
>>>> /Daniel
>>>>
>>>>
>>>> --
>>>> --
>>>> Chromium Developers mailing list: chromi...@chromium.org
>>>> View archives, change email options, or unsubscribe:   http://groups.google.com/a/chromium.org/group/chromium-dev
>>>>

>>>> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Torne (Richard Coles)]

On 10 January 2014 16:00, James Su <su...@chromium.org> wrote:

2014年1月10日 下午11:20于 "Torne (Richard Coles)" <to...@chromium.org>写道：

>
> On 10 January 2014 12:20, James Su <su...@chromium.org> wrote:
>>
>> The real scenario is that a website containing malicious code may control the code injected by a chrome extension (a virtual keyboard in the original case) by faking mouse events to achieve some unexpected goals, e.g. click the virtual keyboard drawn by the extension to input malicious content into an iframe with a page from another website. It's possible because the extension injects code into both outside and nested pages, and the virtual keyboard is drawn on the outside page. It's perfect legal if the user clicks the virtual keyboard to input something into the nested page. But it'll be dangerous if a malicious script in the outside page can do the same thing by faking events. So the virtual keyboard extension surely want to avoid such thing by only accept trusted mouse events.
>
> From this description it sounds like the virtual keyboard is being added to the *page's* DOM by the extension. Am I understanding correctly?
>
> If so, then this is insecure anyway, no? If the threat is "the web page contains malicious JS which wants to force a certain sequence of virtual keyboard clicks", then it seems like you can achieve this without generating any "fake" click events at all just by manipulating the DOM something like this:
>
> 1) Find the DOM node corresponding to the virtual keyboard key you want to be clicked next
> 2) Make a visual duplicate of it to leave in place
> 3) Make the original DOM node invisible in some way
> 4) Reposition that node so that it's always right underneath the user's mouse cursor as it moves
>

Interesting idea, but can't the extension avoid it by chrcking the DOM node's positiion and visibility from time to time?

It *might* be able to catch the page in the act, sure, but then you are playing a cat and mouse game - the author of the page can read the source code for your extension to see what you check, and work around your checks.

 

> Now whenever the user clicks on something on the page, they'll click on the virtual keyboard and type something into your iframe. You can add your own onclick handler to the same DOM node and then have *that* handler inject a fake click event on whatever was underneath at that point on the page, so the user doesn't wonder why their clicks aren't doing anything. If you want a plausible reason for the user to click on your page content a lot without navigating away, just make your malicious page a match-three game. :)
>
> It just seems like there's no way for anything inside the page's DOM to ever be secure against the page being malicious. If an extension wants to provide a virtual keyboard securely this would have to be somewhere *outside* the page's DOM (e.g. in a separate window, or extension popup, or whatever)

It's not practical on chrome, because AFAIU, it's not possible for an extension to show a separate window without stealing the keyboard focus. Please let me know if there is a way to do it.

I'm not saying there *is* a good, secure way to do this, I am just pointing out that this way is not secure and you shouldn't do it :) 

[James Su]

2014年1月11日 上午12:02于 "Torne (Richard Coles)" <to...@chromium.org>写道：
>
> On 10 January 2014 16:00, James Su <su...@chromium.org> wrote:
>>
>>
>> 2014年1月10日 下午11:20于 "Torne (Richard Coles)" <to...@chromium.org>写道：
>>
>>
>> >
>> > On 10 January 2014 12:20, James Su <su...@chromium.org> wrote:
>> >>
>> >> The real scenario is that a website containing malicious code may control the code injected by a chrome extension (a virtual keyboard in the original case) by faking mouse events to achieve some unexpected goals, e.g. click the virtual keyboard drawn by the extension to input malicious content into an iframe with a page from another website. It's possible because the extension injects code into both outside and nested pages, and the virtual keyboard is drawn on the outside page. It's perfect legal if the user clicks the virtual keyboard to input something into the nested page. But it'll be dangerous if a malicious script in the outside page can do the same thing by faking events. So the virtual keyboard extension surely want to avoid such thing by only accept trusted mouse events.
>> >
>> > From this description it sounds like the virtual keyboard is being added to the *page's* DOM by the extension. Am I understanding correctly?
>> >
>> > If so, then this is insecure anyway, no? If the threat is "the web page contains malicious JS which wants to force a certain sequence of virtual keyboard clicks", then it seems like you can achieve this without generating any "fake" click events at all just by manipulating the DOM something like this:
>> >
>> > 1) Find the DOM node corresponding to the virtual keyboard key you want to be clicked next
>> > 2) Make a visual duplicate of it to leave in place
>> > 3) Make the original DOM node invisible in some way
>> > 4) Reposition that node so that it's always right underneath the user's mouse cursor as it moves
>> >
>> Interesting idea, but can't the extension avoid it by chrcking the DOM node's positiion and visibility from time to time?
>
>
> It *might* be able to catch the page in the act, sure, but then you are playing a cat and mouse game - the author of the page can read the source code for your extension to see what you check, and work around your checks.
>  
>>
>> > Now whenever the user clicks on something on the page, they'll click on the virtual keyboard and type something into your iframe. You can add your own onclick handler to the same DOM node and then have *that* handler inject a fake click event on whatever was underneath at that point on the page, so the user doesn't wonder why their clicks aren't doing anything. If you want a plausible reason for the user to click on your page content a lot without navigating away, just make your malicious page a match-three game. :)
>> >
>> > It just seems like there's no way for anything inside the page's DOM to ever be secure against the page being malicious. If an extension wants to provide a virtual keyboard securely this would have to be somewhere *outside* the page's DOM (e.g. in a separate window, or extension popup, or whatever)
>> It's not practical on chrome, because AFAIU, it's not possible for an extension to show a separate window without stealing the keyboard focus. Please let me know if there is a way to do it.
>
>
> I'm not saying there *is* a good, secure way to do this, I am just pointing out that this way is not secure and you shouldn't do it :) 

The problem is that displaying the virtual keyboard inside the page's DOM is the only feasible way we found until now. We need to live with it until there is a better way, but meanwhile we do want to make the current solution as secure as possible.

[Torne (Richard Coles)]

On 10 January 2014 16:12, James Su <su...@chromium.org> wrote:

2014年1月11日 上午12:02于 "Torne (Richard Coles)" <to...@chromium.org>写道：

>
> On 10 January 2014 16:00, James Su <su...@chromium.org> wrote:
>>
>>
>> 2014年1月10日 下午11:20于 "Torne (Richard Coles)" <to...@chromium.org>写道：
>>
>>
>> >
>> > On 10 January 2014 12:20, James Su <su...@chromium.org> wrote:
>> >>
>> >> The real scenario is that a website containing malicious code may control the code injected by a chrome extension (a virtual keyboard in the original case) by faking mouse events to achieve some unexpected goals, e.g. click the virtual keyboard drawn by the extension to input malicious content into an iframe with a page from another website. It's possible because the extension injects code into both outside and nested pages, and the virtual keyboard is drawn on the outside page. It's perfect legal if the user clicks the virtual keyboard to input something into the nested page. But it'll be dangerous if a malicious script in the outside page can do the same thing by faking events. So the virtual keyboard extension surely want to avoid such thing by only accept trusted mouse events.
>> >
>> > From this description it sounds like the virtual keyboard is being added to the *page's* DOM by the extension. Am I understanding correctly?
>> >
>> > If so, then this is insecure anyway, no? If the threat is "the web page contains malicious JS which wants to force a certain sequence of virtual keyboard clicks", then it seems like you can achieve this without generating any "fake" click events at all just by manipulating the DOM something like this:
>> >
>> > 1) Find the DOM node corresponding to the virtual keyboard key you want to be clicked next
>> > 2) Make a visual duplicate of it to leave in place
>> > 3) Make the original DOM node invisible in some way
>> > 4) Reposition that node so that it's always right underneath the user's mouse cursor as it moves
>> >
>> Interesting idea, but can't the extension avoid it by chrcking the DOM node's positiion and visibility from time to time?
>
>
> It *might* be able to catch the page in the act, sure, but then you are playing a cat and mouse game - the author of the page can read the source code for your extension to see what you check, and work around your checks.
>  
>>
>> > Now whenever the user clicks on something on the page, they'll click on the virtual keyboard and type something into your iframe. You can add your own onclick handler to the same DOM node and then have *that* handler inject a fake click event on whatever was underneath at that point on the page, so the user doesn't wonder why their clicks aren't doing anything. If you want a plausible reason for the user to click on your page content a lot without navigating away, just make your malicious page a match-three game. :)
>> >
>> > It just seems like there's no way for anything inside the page's DOM to ever be secure against the page being malicious. If an extension wants to provide a virtual keyboard securely this would have to be somewhere *outside* the page's DOM (e.g. in a separate window, or extension popup, or whatever)
>> It's not practical on chrome, because AFAIU, it's not possible for an extension to show a separate window without stealing the keyboard focus. Please let me know if there is a way to do it.
>
>
> I'm not saying there *is* a good, secure way to do this, I am just pointing out that this way is not secure and you shouldn't do it :) 

The problem is that displaying the virtual keyboard inside the page's DOM is the only feasible way we found until now. We need to live with it until there is a better way, but meanwhile we do want to make the current solution as secure as possible.

The example I gave of how to break the security here is just one of infinite possible ways. You will never think of all of them, or code around all of them. Mitigating just one of the ways to break it is, in my opinion, worse than nothing, because it gives a *false* sense of security. You can't trust anything related to the page DOM if you don't trust the page; don't even try.

You basically have two reasonable choices:

1) Accept that this whole thing is insecure and ship it anyway as-is.

2) Don't ship it at all until you find a way to do it without using the page's DOM (which may involve requesting more extension features from the chromium developers, if there really is no other way to do it now; I don't know).

[James Su]

Thank you for your suggestion. We are thinking maybe we can move the virtual keyboard code into an iframe with a different domain, so that it'll be isolated from the web page. But unfortunately, it requires massive code change.

2014/1/11 Torne (Richard Coles) <to...@chromium.org>

--
- James Su

[Adam Barth]

[+security]

You might what to get someone on the security team to review the design before you make a big effort to migrate to a new design.  I'm not familiar with the details of what you're trying to achieve, but it's likely there are security issues you'll want to consider even with an iframe-based design.

Adam

[Andrew Hintz]

isTrusted has now been implemented for Chrome Extensions:

https://www.chromestatus.com/feature/6461137440735232

https://code.google.com/p/chromium/issues/detail?id=334015

https://googlechrome.github.io/samples/event-istrusted/

Many thanks to dtapuska for doing the work!

[Ivan Castellanos]

Any idea why is there no way to set isTrusted when using dispatchEvent from a Chrome extension? Right now as a extensions developer I have to make the ugliest workaround: modifying all JS scripts on runtime to transform event.isTrusted to true, can't believe there is no way of doing this.

[Dave Tapuska]

You can inject trusted events using the debugger interface.

See: https://stackoverflow.com/questions/46619522/keyboard-simulation-using-a-chrome-extension?rq=1

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/a5cd0182-2ce7-49c1-911d-44a49073b428%40chromium.org.

[Ivan Castellanos]

Thanks for the response. I'm glad there is a way; pretty weird for it to be on the "debugger" namespace since the intended use is to act on the behalf of the user not help him debug anything or fetch any debugging info; plus this means I need to ask the user for "debugging" permissions and that's just gonna confuse the user.

[Dave Tapuska]

Well you are trying to impersonate a real user by injecting input. I presume your extension isn't widely distributed because granting an extension debugging access gives the extension all sorts of functionality that puts the user at risk. 

Dave

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/33cfafc6-3a10-486c-b448-dae23b7de39a%40chromium.org.