504748 - Web sites can make Ctrl+C copy something other than what it looks like you are copying

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Steve-o]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090701 Ubuntu/9.04 (jaunty) Shiretoko/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090701 Ubuntu/9.04 (jaunty) Shiretoko/3.5

Firefox 3.0.11, Shiretoko 3.5 on Ubuntu 9.04. 

As per the following article:

http://support.mozilla.com/en-US/kb/Granting+JavaScript+access+to+the+clipboard

The Esquire site is exploiting this problem:

"A website may change the clipboard data, which may cause different data to be pasted later on instead of the data you intended to paste originally."

Reproducible: Always

Steps to Reproduce:
1.  Ensure JavaScript is enabled.
2.  Visit the Esquire site and wait for page to load.
3.  Select a block of text longer than 4 words.
4.  Copy via Ctrl+C or the menu.
5.  Paste into gedit.
Actual Results:  
The copied text plus the following:

Read more: http://www.esquire.com/features/gerard-butler-interview-0809#ixzz0LUgkZzG9

Expected Results:  
Only the original copied text.

Flash is disabled via Flashblock.  Disabling JavaScript prevents the copy-jacking from occuring.  Researching on Google shows that IE makes this functionality readily available via window.clipboardData, but support in Firefox is deliberately limited for security reasons, requiring explicit permission:

http://kb.mozillazine.org/Granting_JavaScript_access_to_the_clipboard

Chrome 3.0.194.0 returns just a new line on paste.  Opera 9.64 works as expected.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

So, uh, we apparently do all this work to not let web pages touch the clipboard, but we allow them to mutate the selection arbitrarily? Like, say, right before I copy (which we send an event about). We should make the document's selection range immutable to content script or something.

Comment 2

[Benjamin Smedberg]

The website could hide arbitrary data in the selection anyway with display:none blocks... why not let them change the selection? This seems like a feature, not a bug.

Comment 3

[Steve-o]

> The website could hide arbitrary data in the selection anyway with
> display:none blocks.

If display:none content was copied that would be a flaw too.  Yes it should be valid to move the selection to include it, but copy should only copy what it visible to the user, so display:none content would be ignored.

Comment 4

[Jesse Ruderman]

It's not possible to "fix" this from a security standpoint, because there are a gazillion ways a site can mislead you as to the contents of a selection: font-size:0, opacity:0, absolute positioning, fonts that make the character 'a' look like a 'z', image alt text.

So we'd prefer to make copying as usable as possible, and that means including image alt text (bug 212177) and allowing scripts to suggest correct text (useful for bespin, spreadsheets).  We plan to not copy display:none text (bug 39098), not for security reasons, but because users keep hitting it.

See previous security discussion in bug 57770 and bug 39098.

It's unfortunate that Esquire has decided to hurt usability by stuffing their URL into all copies, but they're not being malicious, just greedy.

Comment 5

[Jesse Ruderman]

I am curious what method Esquire is using, fwiw.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

On the copy event, they create a display:hidden div with the "Read more: ..." link as the contents. Then they extend the document's selection range to contain that div.