

Clipboard Hijacking with HTML5 in Chrome - tbranyen
http://tbranyen.com/post/clipboard-hijacking-with-html5

======
userbinator
This needs to be a thing (global, and also per-site):

    
    
        [ ] Allow reading clipboard content
        [ ] Allow writing clipboard content
    

I much prefer the "if there's an API that websites could abuse, there needs to
be a setting to disable it" line of thought when it comes to browser
functionality. I know it could result in many options (how about organising
them better), and cause some to oppose with "but it'll be too hard/confusing
for the users!", but this is how you empower your users to take control of
their browsing experience - with fine-grained controls, not only large
categories, and _certainly not_ "it can't be changed from the UI".

~~~
zimbatm
> Allow reading clipboard content

This should never be a thing. The amount of snooping that's possible is
incredibly high and people don't realize that kind of thing.

------
adam-a
There are also people doing this by listening to the element.copy event then
switching out the selected element. TYNT[0] are the primary culprits (they
promise to let you "leverage on site copy and paste activity"). I found out
about this a while back and made a demo and a small writeup[1].

This method is totally impossible to spot, works for Ctrl-C as well as right-
click copy, and is fairly widely supported.

0 - [http://tynt.com/](http://tynt.com/)

1 -
[http://joeba.in/joebain/Javascript%20Copy%20Hijack](http://joeba.in/joebain/Javascript%20Copy%20Hijack)

~~~
mbrock
Semi-interesting trivia. Trello lets you copy the URL of a card by just
hovering it and hitting Ctrl-C. They do this by intercepting Ctrl to change
the current selection to an invisible input field...

------
fixermark
I'm not really seeing the issue here. So the user agent is allowed (via
Javascript) to modify the content the user copied on its way to the clipboard,
but they're not allowed to read the clipboard without user consent, right?
It's the latter that's scary (allows untrusted client code to see, for
example, maybe my bank account number or a password if I used the system
clipboard to move it around).

I've seen enough legitimate use cases of fixing the browser's mistaken
assumptions of how to translate HTML to plaintext to feel that the benefits to
being able to edit the clipboard output offset the cost of putting up with a
few "Want to read more? [mysite]" edits.

~~~
tbranyen
"I'm not really seeing the issue here."

"...to modify the content the user copied on its way to the clipboard..."

The browser can copy data into your clipboard without you requesting anything.
Your assumption is that the user hit Ctrl+C and the app augmented the value,
which is not the case in my post.

~~~
fixermark
Ah, thank you for the clarification.

------
nailer
This doesn't seem to be so much 'clipboard hacking' as 'select highjacking'.
It's a small distinction, but this attack has been around since before the
HTML5 clipboard API, and the actual clipboard API does pop down an allow/deny
box, eg like a webcam access does.

~~~
tbranyen
Huh, it does not in desktop or mobile. What browser/os are you talking about?

~~~
robin_reala
It does in IE.

~~~
tbranyen
Well this post is about how Chrome screwed up, so props to IE for doing the
right thing :)

------
jimrandomh
I'd like to put in another word for an explicit per-site permissions model. I
have a project which is (among other things) a terminal emulator, which runs
in Chrome's App Mode. It has a scripting system in between the keyboard and
the user's actions, which is not Javascript and lives outside the browser.
Right now, copy and paste are ugly hacks because Chrome restricts clipboard
access to inside of event-handlers, which doesn't allow the necessary
roundtrip to interpret the keystrokes.

------
mkozlows
To tldr this:

1\. It does not allow web pages to read the clipboard (which would be a
security violation, and what comes to mind when you say "hijacking"), only to
write to it.

2\. Browsers can already trap clicks and keys to override standard copy
functionality, so if you're worried about Tynt-style stuff, this doesn't
change that equation at all.

3\. The only effect of this is that it lets sites overwrite your clipboard
when you don't signal that you want to copy something. Which they could
already do today if you have Flash.

So... at worst, that counts as a minor annoyance. And since most sites aren't
actively hostile to their users, it's not likely to be widely-misused, and
it's more likely that it'll be used for its intended purpose -- making it easy
for users to copy, say, big wodges of code to the clipboard with a single
click.

The proposed solution to this non-problem would make this feature so
cumbersome it might as well not exist, on its way to solving a problem that in
practice will almost never be seen.

~~~
tbranyen
1\. The term clipboard hijacking predates my post, so I don't get your point.
And yes, if it could access your clipboard that would be insanely insecure.

2\. This has nothing to do with overriding standard clipboard functionality.

3\. "Due to browser and Flash security restrictions, this clipboard injection
can ONLY occur when the user clicks on the invisible Flash movie. A simulated
click event from JavaScript will not suffice as this would enable clipboard
poisoning."

So no, this cannot occur already with Flash. Simply hovering over text is
enough with this new API to augment your clipboard.

At worst this overrides your clipboard which could contain important
information. Visiting a click bait site accidentally could potentially destroy
your work (assuming it was in the clipboard).

How often do you use this feature already? Would it really make it so
cumbersome that you'd never use it. Do you never use location, microphone,
full screen, webcam, etc APIs because they ask for permission? I doubt it.

I think it's a bit bold and bit too early for you to be making any claims
about whether or not this will be abused. I think you have far too much trust
in advertisers.

------
skrowl
I'm sure advertisers will love this.

One more reason to upgrade to FOSS Mozilla Firefox.

~~~
robin_reala
You’re out of luck I’m afraid, they’re implementing it too:
[https://groups.google.com/d/msg/mozilla.dev.platform/oWhmLMv...](https://groups.google.com/d/msg/mozilla.dev.platform/oWhmLMvGAD0/3eXWSRjJAZsJ)

------
owencm
This was already possible on desktop using the following flash polyfill:
[https://github.com/zeroclipboard/zeroclipboard](https://github.com/zeroclipboard/zeroclipboard).
So on desktop at least this doesn't introduce any new threats, so this seems a
little strongly worded to me.

~~~
tbranyen
Except that this is baked into the browser and affects mobile. It's also been
discovered that your clipboard can be hijacked by purely loading a page. So
yeah, I think the threat is very real and very obnoxious.

------
TD-Linux
One important thing to note is that this functionality is also available
through Flash. So, anyone who has Flash enabled has already been vulnerable to
this.

We haven't seen anything terribly bad happen with the Flash implementation.

~~~
federicobond
But if we are going to provide a modern, standard API, then we better make it
right.

A possible attack scenario could be showing a certain Bitcoin address but
copying a different one to your clipboard.

~~~
iopq
You try to copy a Bash snippet and it gives you something very dangerous
instead when you paste...

------
lloeki
An article's comment reports it works in Firefox, here it seems to work in
Safari too.

------
zodiakzz
This is the kind of feature which should be HTTPS-only :)

