Hi, Anyone? If you don't consider this as security bug, please let me know.

This is an unconvincing attack scenario. It is extremely unlikely to convince the user to drag stuff to arbitary tabs.

Hi,

Attacker can use below cursor hack to fake cursor location and let victim play a game where victim drag and drop things, but as cursor location is manipulated by attacker, victim thinks that he is droping things in document but it is actually tabs.

https://jameshfisher.github.io/cursory-hack/

+dcheng for drag & drop expertise

While I agree the attack scenario is not likely to happen, I think we can improve the situation a bit.

E.g. why do we even allow drag and drop of javascript: URLs between different origins? Is there a compelling use case to keep that behavior? Can we just ignore drop events with javascript: URLs on tabs?

> Can we just ignore drop events with javascript: URLs on tabs?

That seems like the safest approach and one that would close down the myriad variations on this vulnerability theme.

> between different origins?

One important caveat is that the source of the drag won't necessarily have an origin, as drops can come in from elsewhere in the system. For example, on Mac, open TextEdit, type javascript:alert(1) in the editor, select the text, and drop it to Chrome's tab and watch it navigate. Similarly, a user could add a "bookmarklet" to their bookmarks bar and then drag/drop that bookmarklet to a different tab than the one they're on. (Some tiny number of ultra-power users probably consider this a part of their workflow). We could /try/ to minimize the impact by only rejecting drops that originated from untrusted web content (e.g. by tagging the clipboard with an untrusted-flag) but these approaches quickly get complicated and I'm unconvinced that it's worth the effort.
 
Likely place to insert a guard?
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/DragController.cpp?q=navigateOnDragDrop&sq=package:chromium&dr=C&l=274

What do Edge / Firefox do? Do they just not allow this drag? Or do they not support dropping on a tab to navigate it?

Also, we already mark the drag data (https://cs.chromium.org/chromium/src/content/public/common/drop_data.h?rcl=0&l=65) if it originated from a untrusted web content, so we can just use that. Obviously, it doesn't work if you drag from FF into Chrome... but you're kind of just asking for trouble at that point?

tl;dr-- Of IE, Edge, Firefox, and Chrome: only Chrome allows navigation to JavaScript via drop.

Edge 39.14915.1000 and IE11 both allow the drag operation for a JavaScript URL object to start, then:

1. If you try to drag the JavaScript URL to a tab, there's a brief flicker of the "No Drop" icon (ISO 3864-1 prohibited) before nothing happens.
2. You can drag the JavaScript URL to Chrome which will execute it in the page's contexts under the right conditions (IE in Protected Mode requires the target app to register for Elevation to get Drops)
3. You can drag the JavaScript URL to ClipSpy to display the clipboard formats (if IE not in protected mode or if the app is registered for Drop Elevation)

Dragging an HTTPS or AppProtocol URL object from IE content to IE tabs navigates the tab.

Dragging any URL object from Edge content or Chrome to Edge has no effect; the No Drop icon is shown.

Dragging a JavaScript URL object from Chrome to IE's Active tab results in a prompt asking the user for permission to "Add this bookmarklet, which can run script and send information to the Internet"; if the user clicks Yes (default) then the script runs. (IE simply repurposed the existing dialog shown when the user creates a Favorite that contains a script URL).

Dragging a JavaScript URL object from Chrome to any *background* tab in IE hangs the entire process, almost certainly an IE bug caused by a conflict between the modal "Add this bookmarklet?" prompt and the dialog suppression shim that tries to prevent background tabs from popping dialogs. Oops.

Dragging a JavaScript URL to Firefox 50a2 tabs from Firefox or Chrome results in no action. Dropping a HTTPS or AppProtocol URL object from Firefox or Chrome causes Firefox to navigate to the target URL.

Assigning severity.

Hi, thank you all for reconsideration. Do you consider this as SOP bypass?

After thinking about this, I don't think there's any good reason to allow dropping javascript: URLs, trusted or not. We already prevent pasting javascript: URLs in the omnibox (well, we strip "javascript:"), so in that respect, this is pretty similar.

Using trick below, dropping into new tab will also cause XSS in Google.com :p
 https://crbug.com/554519 

I'd like to take a swing at this.

https://codereview.chromium.org/2323273003

> Hi, thank you all for reconsideration. Do you consider this as SOP bypass?

This is more akin to self-XSS than a straightforward SOP bypass as it requires significant user interaction.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d1a8cbeec4d9f9520a4bb1f4db6d3f62900ee709

commit d1a8cbeec4d9f9520a4bb1f4db6d3f62900ee709
Author: elawrence <elawrence@chromium.org>
Date: Wed Sep 14 18:38:43 2016

Ignore Javascript urls dropped on tabs

When a Javascript: url is dropped on a tab, it executes in the
security context of the selected tab, representing a script
injection attack ("Dropjacking"). We will match other browsers
and disallow such drops.

BUG= 639750 

Review-Url: https://codereview.chromium.org/2323273003
Cr-Commit-Position: refs/heads/master@{#418620}

[modify] https://crrev.com/d1a8cbeec4d9f9520a4bb1f4db6d3f62900ee709/chrome/browser/ui/views/tabs/tab_strip.cc

https://whytls.com/test/drag/javascript.html is a simple test page useful for verification.

Windows fix in 55.0.2861.0 is ineffective on Mac.

Mac appears to go through a different codepath, using URLDropTarget.

We'll need to update dropURLs (and maybe isUnsupportedDropData) in tab_strip_controller.mm.

On Mac, dropping on the omnibox/location bar also navigates instead of copying the text. This in toolbar_controller.mm looks dodgy:

// Detect JavaScript and sanitize the text in the Omnibox
  if (url.SchemeIs(url::kJavaScriptScheme)) {
    browser_->window()->GetLocationBar()->GetOmniboxView()->SetUserText(
         OmniboxView::StripJavascriptSchemas(base::UTF8ToUTF16(url.spec())));
  }

// Ignore what we just shoved in the omnibox and navigate to the JavaScript URL:
  OpenURLParams params(url, Referrer(), WindowOpenDisposition::CURRENT_TAB,
                       ui::PAGE_TRANSITION_TYPED, false);
  browser_->tab_strip_model()->GetActiveWebContents()->OpenURL(params);

https://codereview.chromium.org/2346023002/#

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a2525d33673bd4a5987a9aa3dfb516f6c89fb6de

commit a2525d33673bd4a5987a9aa3dfb516f6c89fb6de
Author: elawrence <elawrence@chromium.org>
Date: Fri Sep 16 20:14:03 2016

Ignore Javascript urls dropped on tabs (Mac version)

When a Javascript: url is dropped on a tab, it executes in the
security context of the selected tab, representing a script
injection attack ("Dropjacking"). We will match other browsers
and disallow such drops.

Mac handles URL drops using a different codepath than Windows;
this change fixes the Mac codepath.

BUG= 639750 

Review-Url: https://codereview.chromium.org/2346023002
Cr-Commit-Position: refs/heads/master@{#419266}

[modify] https://crrev.com/a2525d33673bd4a5987a9aa3dfb516f6c89fb6de/chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm
[modify] https://crrev.com/a2525d33673bd4a5987a9aa3dfb516f6c89fb6de/chrome/browser/ui/cocoa/toolbar/toolbar_controller.mm

Dev-Verified the fix on Mac. 

Mac fix landed in 55.0.2863.0

 Issue 660774  has been merged into this issue.

 Issue 666735  has been merged into this issue.

Any chance of bounty?

I'm afraid we don't usually consider a bounty for low severity bugs. It will get a CVE assigned, though.

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

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot