Clipboard Hijacking with HTML5 in Chrome | Hacker News Reader

Clipboard Hijacking with HTML5 in Chrome

tbranyen.com

73 pointstbranyen31 comments

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".

"Allow reading clipboard content"

As in something similar to how clipboard contents can be gleaned in iOS by a simple API call? I always wondered how many apps were abusing that iOS (feature?) and posting it to a collection server.

This is something I wished browsers would do in general.

> 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.

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/

1 - http://joeba.in/joebain/Javascript%20Copy%20Hijack

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...

If you just want to inject things into a copy-paste, you don't even need javascript: http://www.lattyware.co.uk/examples/injecting-text-into-clip...

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.

"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.

Ah, thank you for the clarification.

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.

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

It does in IE.

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

On phone on bus, but the actual clipboard API, I.e. new ClipBoardEvent, should ask permission. Note changing the selection is not the clipboard API and will not ask permission.

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.

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.

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.

+100

> And since most sites aren't actively hostile to their users,...

What web are you browsing? Tynt still exists. "Give me your email" popovers exist. Many sites won't display a simple 1000-word article without loading gobs of JavaScript I don't want. Websites are so terrible that most browsers have a "make the content readable" button. Most of the web is actively hostile.

I absolutely don't want this feature and the problem is not that HTML5 is not on par with Flash, but that Flash was able to do it in the first place.

Am I the only one who uses and likes click to play for flash? Great way to block clipboard hijacks. And now there is no click to play for html5-clipboard API.

There must be a user prompt before a website captures a hover, mousover or EVEN CLICK and decides to overwrite the current code, mail or whatever valuable thing I currently have in my clipboard with advertising links!

I'm sure advertisers will love this.

One more reason to upgrade to FOSS Mozilla Firefox.

You’re out of luck I’m afraid, they’re implementing it too: https://groups.google.com/d/msg/mozilla.dev.platform/oWhmLMv...

> One more reason to upgrade to [...]

One more reason to downgrade to text-based downloads?

This was already possible on desktop using the following flash polyfill: 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.

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.

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.

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.

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

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

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

Reply on news.ycombinator.com