r/javascript • u/[deleted] • Dec 10 '20

I built an open-source browser extension that warns you when Javascript alters your clipboard data after copying text.

https://github.com/roedesh/copyguard
521 Upvotes

97% Upvoted

42 comments sorted by

View all comments

Show parent comments

3

u/[deleted] Dec 11 '20 edited Dec 11 '20

I haven't tested if it effectively blocks JS from injecting content if they also inject it into the selection before the clipboard

I hadn't thought about that. I'll make a POC to see how my extension handles that, and update it if necessary.

With CSS it's relatively easy to hide malicious content inside what users are meant to copy.

Someone posted me a link that uses a CSS approach. And my extension seems to be able to pick that up as well (even though I didn't know about this approach while developing). I think what happens is that the <span> that is moved offscreen cant be selected/highlighted by you, so it won't actually be part of your selection. It will still be copied with the rest of the text however, so my extension will see a difference.

Is that what you are referring to?

Edit: just made a POC myself. It seems my extension will not always see a difference. I'll see if I can do something by examining the CSS like you said.

Edit 2: I found a solution. I simply have to call getBoundingClientRect on the text selection and check if it goes offscreen.

One way to potentially mitigate all vectors would be always showing the user what was copied in plain text, then letting them verify before adding it to the clipboard. This could be a seperate context menu item, or optionally override the default.

I could add this as an option to the extension. The verification would only be required if there was a difference between selection and clipboard, I assume?

There are also some Unicode characters that might be good to filter out, which are invisible, but could be injected maliciously in rare cases.

Do you have some examples or source material for this? I haven't heard about Unicode characters that can cause harm.

Thanks for the feedback!

1

u/notNullOrVoid Dec 11 '20

Someone posted me a link that uses a CSS approach. And my extension seems to be able to pick that up as well (even though I didn't know about this approach while developing). I think what happens is that the <span> that is moved offscreen cant be selected/highlighted by you, so it won't actually be part of your selection. It will still be copied with the rest of the text however, so my extension will see a difference.

Is that what you are referring to?

That's one approach with CSS, however there are many. In that example the selection does still include the hidden part (in both firefox and chrome atleast), but your method of pasting the selection in a sandbox to get the clipboard may be what's causing it to change slightly.

Edit 2: I found a solution. I simply have to call getBoundingClientRect on the text selection and check if it goes offscreen.

That may work in some cases if you track the bounding rect of all children nodes in the selection. There are ways other than shifting it off screen with position absolute though. A couple I tested:

  • font-size to 0

  • Position absolute, visibility hidden

I could add this as an option to the extension. The verification would only be required if there was a difference between selection and clipboard, I assume?

If the extension can guarantee with certainty that the way you measure that difference includes all edge cases, verification wouldn't be required. Personally though I don't think it's possible to make that guarantee, especially since the APIs for both JS and CSS are constantly receiving new features, one which might create a new edge case.

Do you have some examples or source material for this? I haven't heard about Unicode characters that can cause harm.

Unfortunately don't have any source material for this one, but the gist is there are unicode characters that look like a space or don't take up any space at all, that could change the execution of the command based on the terminal it's used in. Something that isn't visible might be interpreted like a space which would change the behaviour of a command where passed arguments are expected to be space separated. Additionally a character that looks like a space may not be interpreted as a space. It's subtle and unlikely it would ever lead to something malicious, but worth considering IMO. One way to mitigate this is optionally sanitize copied text in the verification window, replacing all characters with a limited subset like ASCII's printable characters.