14

It seems there is currently no pure JavaScript method for accessing the system clipboard using most modern browsers, Internet Explorer being an exception. On numerous other Stack Overflow questions (e.g., Clipboard access using Javascript - sans Flash?) it's explained that this limitation is a deliberate security measure to protect against web sites reading passwords or other sensitive data from the clipboard.

While it seems obvious that reading from the clipboard would be a huge security risk, it's not clear to me why writing to the clipboard would be. What scenario, if any, are browsers protecting against by denying JS the ability to copy data to the clipboard?

Community
  • 1
  • 1
goodside
  • 3,907
  • 2
  • 18
  • 26

4 Answers4

16

Writing to the clipboard is a way for malicious web sites (or other code running within sites, such as flash-based ads) to trick users into spreading malware. This happened a few years ago with flash-based ads that copied a malware URL onto the clipboard, in hopes that users would paste it when they intended to paste something else, thus polluting things like facebook posts, forums, and e-mail. Instead of a link to a photo of Aunt Tilly's cat, you'd paste a link to some drive-by malware. Typically these were the "you've been infected with a virus, pay us $50 for the removal software" fake antivirus scams. I did some research on it, as a lot of my ClipMate customers were asking why these nasty URLs were suddenly appearing in ClipMate. While researching, I was attacked by flash-based ads on MSNBC and DIGG. The clipboard has been subsequently locked down in Flash 10. You can read more about my saga here: http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous

I expect that the JavaScript restriction is to prevent similar things from happening.

Chris Thornton
  • 15,250
  • 4
  • 34
  • 61
6

What if the user doesn't want his or her clipboard overwritten?

Delan Azabani
  • 73,106
  • 23
  • 158
  • 198
  • Exactly. For instance, a user with KeePass may have a password he needs in his clipboard, and overwriting the data he wants to store with yours would be destructive and annoying, which is why browsers wouldn't want this behavior. – mopsled Aug 14 '11 at 22:25
  • 2
    Flash only supports it when clicking something. I don't see the security hole if it was implemented in JavaScript the same way. It would save a lot of trouble with those Flash solutions. – pimvdb Aug 14 '11 at 22:35
  • 2
    I'll accept this if nothing more compelling shows up, but this seems like a trivial reason to disable something potentially useful. Losing the clipboard is an annoyance at worst, since there's no expectation that it's a long-term storage locker for important data. Also, there are countless other ways to annoy users with JS that are universally supported, like creating pop-up notifications. – goodside Aug 14 '11 at 22:52
  • 1
    +1 for not going behind the user's back. Changing a deeply ingrained UX expectation -- that the clipboard is something that exists within a frame of reference outside, and not accessible to, web app code -- is a bad idea. – Ken Redler Aug 14 '11 at 23:14
3

If the user expects that their clipboard contains one thing, but covertly it's been replaced by another thing, even that's a potential security problem, not just an annoyance.

Although an unlikely attack vector, it's not unreasonable to think something could be dreamed up that involves social engineering: convince the user to paste covertly altered information into a password field on a target resource. That resource would then be secured by a password known to the attacker.

Ken Redler
  • 22,899
  • 7
  • 55
  • 68
0

Aside from abovementioned vulnerability issues there's at least one scenario where imporper implemetation of javascript clipboard API can raise some security concerns.

Nowadays we have new APIs for establishing connection between separate windows without invoking server-side, like postMessage, MessageChannel or, say, BroadcastChannel recently introduced to Firefox. These APIs has different level of browser support but all of them are considering cross-origin issues. That is, it should be impossible to recieve a message from a window on a different host unless this window actually explicitely allows it.

This doesn't hold with clipboard API. Imagine that some code on the page pastes code to clipboard and this clipboard is scanned by some another window. This is some very strange and highly hypotetical scenario depending on some quite strange and exotic assumptions, but it worth to mention it.

shabunc
  • 17,863
  • 15
  • 68
  • 96