Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
This site will be read-only for 3-4 hours starting at Sunday, 08:00AM PDT
Starred by 18 users

Issue metadata

Status: Fixed
Closed: Nov 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Security: do not allow on-page drag-and-drop from non-same-origin frames (or require an extra gesture)

Reported by, Oct 13 2010 Back to list

Issue description

This problem is making rounds on internal mailing lists for a while (brought up by BJ a while ago, then by David Bloom), and I think it's time to do something about it. There were real-world examples of such attacks against popular sites (Facebook, to be precise); and as outlined below, mock scrollbars offer a particularly unobtrusive and likely vector for delivering this attack.

The problem is, in essence, that may include a hidden IFRAME pointing to, and have it track mouse movements. For the attack to work, it then needs to solicit the user to select the contents of that IFRAME.

To select text, at least one-pixel movement of the mouse pointer while the left button is pressed would be required; this enables selection mode - and once this is done, the attacker can reposition the IFRAME so that this action selects the entire text, regardless of its actual length. Two simple and common ways to solicit this UI action would be:

1) Having the user interact with a specially crafted scrollbar (e.g., in a "you-must-scroll-down-before-clicking-accept" EULA, or in a partly visible article) - most users grab the slider, drag it, then release it.

2) A casual game that involves drawing or a similar activity. [ Games also allow this to be exploited with triple-click. ]

Once the text is selected, the same single pixel drag-and-drop action needs to be solicited again (e.g., further scrolling). The action needs to start over selected text, and end over a receiving container. At this point, the content is copied over across domains without user's knowledge or consent.

I strongly believe this is not a sophisticated or unlikely attack scenario, and that browser-side fixes are necessary. A simple solution is to prevent cross-domain drag-and-drop on a single page altogether (we can have dev channel experiments to see how many problems this causes - but I suspect not many); or to require a secondary gesture to approve dropping in such a case (e.g., "hold shift to paste here" tooltip).

Note that in conjunction with view-source:, this can be used to steal raw HTML (and in all cases, works for non-HTML documents) - so JavaScript defenses such are not viable. X-Frame-Options offer some defense, but only to a subset of sites.

Labels: SecSeverity-Low OS-All
Status: Available
Drag and drop might need a fundamental change here and it will good to get suggestions from UI team on possible options here. We also have another bug where drag and drop from one window to another window results in the second window being navigated to chrome:// urls (also file:// urls but that is not useful). (D&D not on url bar, but any section on window). In this case, we might want to think over the broader option of evil site opening a new window(s) (/overlapping) and convincing user to drag and drop using games.

Comment 2 by, Oct 18 2010

Labels: -Area-UI
This strikes me as a simple question of whether or not we should block dragging and dropping a selection between non-same-origin frames. I don't see that it involves UI. Although, we might want to pose the question on Chromium dev, since there may be legitimate use cases that we're missing but a broader audience would catch.

Comment 3 by, Oct 18 2010

Now that I think about it, I'm pretty certain this change would have to go into WebKit as opposed to Chrome. So, we'd probably have to push the discussion up there.

@abarth, what's your opinion on this? It seems like blocking DnD between origins is a reasonable precaution that shouldn't break legitimate sites, but maybe there's something I'm missing.
Filed for comments. Have a patch ready, still need to work layouttest. 

I was discussing this Justin and we think we should just block drag and drop across different http(s) domains. This will still allow all other usecases of drag drop across data: urls, file: urls, ftp: urls, etc.

Status: Assigned
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Mstone-9
Status: Fixed
Committed r71925: <>. Will let it picked up in M9 so that it has enough time to stay on trunk and any compatibility issues get noticed.
Followup patch to enable drag drop of same security objects for unique origins -
Labels: CVE-2011-0166

Comment 9 by, Mar 21 2011

Labels: Type-Security

Comment 10 by, Mar 24 2011

Labels: SecImpacts-Stable
Batch update.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Project Member

Comment 14 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 15 by, Mar 10 2013

Labels: -SecSeverity-Low -Mstone-9 -Type-Security -SecImpacts-Stable Security-Severity-Low M-9 Security-Impact-Stable Type-Bug-Security
Project Member

Comment 16 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 17 by, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 18 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 19 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 20 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
 Issue 251718  has been merged into this issue.
Components: Blink>DataTransfer
 Issue 597870  has been merged into this issue.