[w3c/clipboard-apis] Active malicious PasteJacking exploits in-the-wild affecting user security owing to lack of sufficient consideration to identified and other security concerns (#142)

The use-case for permitting a browser to store different content to that which a user expects or intends is strenuous at best, and every case identified is easily implemented with alternative mechanisms.

Additionally, it is debatable whether it is *ever* possible for a paste buffer to recieve something different to that which a user copied in a way that any user might consider "what they intended".  If you include the fact that no other applications in existence ever do this already, the debate looks unwinnable: no user would ever expect "copy/paste" in a browser to behave differently to ever other time they've ever use copy/paste before.

Multiple sites are now injecting malicious content into pasted operations - including modified-source-code websites (inserting maliciously altered code) and modified-CLI-sites (inserting linux command line operations that a user did not want).  Many other security considerations are also missing for your examples - like alteration of payment address (account numbers, cryptocurrency addresses, financial numbers like amounts (e.g. "$12.37" .vs. "$1237")), CR/TAB characters which can cause actions to occur immediately, subtle alteration of computer code to perform malicous actions (install malware, steal money, siphone off cryptocurrencies), and many more.

Section 10.1. "Pasting HTML and multi-part data" fail to even consider that *other* applications besides browsers will be consuming this potentially malicious content (despite that being one of the named use cases).

There are no identified use cases that warrant the introduction of the malicious opportunities that PasteJacking permits:

* Metadata - not need - "the source of the copied content" can be shown in text on the content being copied - if the user wants that, they can explicitly select and copy it.

* Rich content editing - not needed - "text which contains hyperlinks or other structure" is *already preserved* when pasted into applications that understand how to preserve it.  No website could ever know where a user intends to paste copied content, so there is no possible use case for that site to "reformat the content to preserve important information", because the site doesn't know the capabilities of where the content will be pasted into.  In most situations, even attempting to "preserve important information" is more than likely going to damage that information (if the target system understands how to accept a rich paste, having that richness removed damages the very information this proposal is supposed to support).  Users who want a rich paste, are going to paste into an application that accepts it.

* Graphics with built-in semantics - not needed - same as above - the website can never know where pasted text is intended for.  Math sites which wish to allow users "copy/paste" features for other applications can easily implement a suitable mechanism by giving the user a choice of what kind of target their copy operation is intended for.  There is no use case for doing this automatically, because the web page can never automatically know the capabilities of the intended paste target.

"the appropriate transformation occurring at paste time." - this is impossible, because no web site can know the paste-target capabilities without first asking the user (which is easy to do, and does not require exposing users to PasteJacking attacks for webmasters to implement).

Consider "\n rm -rf / \n" being added to a linux command line instructable !

In addition - "copy" is not the only possible action.  Sometimes "cut" takes place.  Alterations to what was "cut" in this situation results in "important information" becoming irrevocably lost - that is directly the opposite result to one of the intended use cases!

I propose:

Remove all capability for browsers to insert content into clipboards that has not been explicitly chosen by the user to be copied (and/or cut).  No modification. No addition.  Receiving something different (and potentially malicious, and almost always unwanted) into a paste buffer to that which was selected by the user is near-universally unintended, universally unexpected, potentially catastrophic, and does not have any demonstrated use-case that is not already easily implemented using alternative and safe existing mechanisms.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/142