Possible exploit: auto-clicking webapp

[vintprox]

There is a probability of edge case where Mastodon web application might be exploited by some instance admin (or fork by association) to automatically click "boost", "favourite", "follow", etc., which can go undetected for enough time.

To recap, web application will be able to do malicious actions on behalf of the extension's user (there is few that it can do, but still significant). Already seeing a potential for dispatchEvent there.

I don't yet know how to warrant solid safety from this exploit, here are just some options I considered:

• place a warning in extension's menu;
• make up a list of possible violators as a blacklist (which is not really an option, given the little age of window for exploit);
• intercept such clicks, but somehow detect whether they were really done by hand (should find a way that can't be reproduced by a script) - if action is not made by user interation, simply don't mirror it to original instance.

[Lartsch]

Hi, not sure if I fully understood what you mean. Can you give an example of what an instance admin could to to abuse this?

The API token which is used for the POST requests should not be accessible by the web application.

[vintprox]

Can you give an example of what an instance admin could to to abuse this?

Given they own what they run, they can insert JavaScript that would trigger click event on "boost", "favorite", "follow" and other buttons for any posts of their choice. That's the gist of it.

The API token which is used for the POST requests should not be accessible by the web application.

Yes, but it doesn't stop from click emulation via dispatchEvent. It is enough for exploitable bug, because it's handed down to extension. The problem is extension doesn't yet discern what is real user interaction and what is scripted.

[Lartsch]

Okay, get it now. I will look into it. A trivial way to differentiate between a user initiated click and a script initiated click would be to check for mouse coordinates. But with dispatchEvent, these could he faked as well.

I can think of some other ways, but none of them can guarantee that it's a user click.

So not sure yet how to differentiate reliably. Please create a pull request if you come up with sth.

[vintprox]

Found out that Event.isTrusted is one reliable way to check for genuine user click/press.

Even redefining custom event interface with faked isTrusted = true won't pass the error like Uncaught TypeError: can't redefine non-configurable property "isTrusted".

Doing a PR now 😊👍

[Lartsch]

Now that's a perfect & simple solution! Did not know about this property yet.

[Lartsch]

I added the required checks with commit https://github.com/Lartsch/FediAct/commit/411dc65573caf74435fc25534107a5c701d0d1aa

Will be included in the next update.

Cheers!

[vintprox]

Ah, OK, I was very busy lately anyway, so I appreciate you taking it over, @Lartsch. Good stuff!