I was testing and comparing the drag-and-drop functionality between browsers and noticed an odd behavior:

1. If a user performs a drag of a URL from inside a same-origin iframe and drops it outside of the iframe, no navigation is performed.
2. If a user performs a drag of a URL from inside a cross-origin iframe and drops it outside of the iframe, a navigation is performed.

This navigation ends up sending all the user's cookies in the request (Lax, Strict, and None), which defeats the purpose of SameSite Cookies on Strict mode for GET requests as this turns all drag-and-drops into potentially untrustworthy actions.

Note that no navigation is made on Google Chrome and Safari.
I have also attached a video reproducing the attack.

VERSION
Version: 105.0 (64-bit).
Operating System: Ubuntu 20.04

REPRODUCTION CASE

1. Download "index.html" and serve the file through a web server.
2. Access https://lbherrera.github.io/lab/setCookies.html to set different SameSite Cookies on the victim's page (Lax, Strict, and None).
3. Access http://localhost/index.html
4. Try to scroll the page down by dragging the scroll bar and then drop it.
5. You will be redirected to https://lbherrera.github.io/lab/getCookies.html and it will display which cookies it received (Lax=true; Strict=true; None=true).

CREDIT INFORMATION
Reporter credit: Luan Herrera (@lbherrera_)

Tentatively moving to DOM navigation as IIRC that handles drag/drop of links as well as the principals used for the loads (which in turn get used for samesite etc.).

There are two separate issues I think:

1. should this drag and drop trigger a navigation?
2. should SameSite cookies be sent.

If we fix 1. we don't really have to worry about 2., but I'm not sure 2. is a bug. We often treat drag and drop navigations as user shortcuts for typing a URL into the navigation bar, and for those SameSite cookies would be sent. But then, the sec-fetch- headers sent in this case are not consistent with that so I'll need to dig deeper.

It looks like this is not happening in chrome because they don't allow you to drag & drop a link within the same tab. We have a similar check for that, though it might be flawed in some way, which we want to fix: https://searchfox.org/mozilla-central/rev/7b5c93295ea5071d3cc5b3ac21c6e8e654f69e1b/dom/base/ContentAreaDropListener.jsm#246-274

I'm not sure this has much to to with same-site cookies. If you drag this into a new window on chrome/edge, it will also load the page with same-site cookies. Same deal with if this was dragged up into the tab strip on the same window.

comment 4 confirms that Chrome looks at this similarly to us: drag and drop is effectively a user-triggered navigation and sends same-site cookies (my issue #2 in comment 3). But allowing drags across origins within the same top-level window makes it easy to fool users that that's what they're doing. Chrome's behavior is safer on issue #1.

from mccr8: Edge behaves like Chrome, but has a red-cross-circle 🚫 cursor while dragging cross the same tab to indicate it's a drag and that drop isn't allowed.

The severity field is not set for this bug.
:sefeng, could you have a look please?

For more information, please visit auto_nag documentation.

mozSourceNode is null if the drag is initialized from different content process, so we are not able to use it to check whether dnd happens within the same tab, there is sourceWindowContext in https://searchfox.org/mozilla-central/rev/a44deb21744de6269329b05461c55488a147f95e/widget/nsIDragSession.idl#48-54 which indicates the windowContext where the drag was started, maybe we could try to use it instead.

Use WindowContext to check if drag source and drop target are in the same tab; r=webidl,smaug
https://hg.mozilla.org/integration/autoland/rev/40a682c088503a4ce664210be0fa22ede1a1d282
https://hg.mozilla.org/mozilla-central/rev/40a682c08850

The bounty is being awarded for the spoofability (and browser parity) of the same-tab navigation. the SameSite cookie behavior for a top-level navigation (when dragged to a completely new window/tab) is consistent with how other browsers conceive of this action.

Please nominate this for ESR102 approval when you get a chance.

Hello.
While testing on Ubuntu 20.04 with Firefox 105.0 (the one in which the issue was reported) and Firefox 109.0b4 (latest beta), the behavior is the same between them.
Like in the attached video, the same webpage with cookie result is shown.

Is the testing valid, or is there something else that can be tested?

(In reply to Virgil Sangerean from comment #12)

Hello.
While testing on Ubuntu 20.04 with Firefox 105.0 (the one in which the issue was reported) and Firefox 109.0b4 (latest beta), the behavior is the same between them.
Like in the attached video, the same webpage with cookie result is shown.

Is the testing valid, or is there something else that can be tested?

Hey, so I tried to reproduce this issue on 109.0b7 (64-bits) and wasn't able to do so. When I drag and drop the scroll, I don't get a navigation anymore. Not sure what happened on your end but I think the fix should have prevented it from happening.

Comment on attachment 9306937 [details]
Bug 1794268 - Use WindowContext to check if drag source and drop target are in the same tab;

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Allowing drags link from across origins within the same top-level window makes it easy to fool users that that's what they're doing.
• User impact if declined: Page is navigated while dragging link from across origins within the same top-level window, this is easy to fool users.
• Fix Landed on Version: 109
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk as the changes are straightforward.

Comment on attachment 9306937 [details]
Bug 1794268 - Use WindowContext to check if drag source and drop target are in the same tab;

Approved for 102.7esr.

https://hg.mozilla.org/releases/mozilla-esr102/rev/23a70c6e8db7

Hello.
The issue is still reproducible on our end on all Firefox versions, pre and post fix.
Please see the attached gif with the behavior.

The issue is not reproducible on Google Chrome, but always reproducible on Firefox 109.0b9, Firefox Nightly from 5th Jan 2023 and 102.6.0 ESR Firefox.

Okay, I think I know what goes wrong here, the patch does fix the issue of dragging a link from cross-origin iframe and dropping it outside of the iframe. But the test case post here removes the iframe while dragging and the patch seems doesn't work for that case. I guess I simplify the original test script while developing the patch and somehow miss to test the original test script while verify my patch, apologies for that :(. Given the patch land here do fix some cases, so I keep this bug close and file a new bug 1809122 for the iframe removal case.

STR:

1. Try to scroll the iframe down by dragging the scroll bar
2. drop it on green area.

Hi Virgil, I update the test script to the case have been fixed in this bug, could you use it to verify this bug? I split the original test to bug 1809122, we could verify that there.

Thank you for the clarification!

Confirmed as verified fixed in Firefox 109.0b8 and Firefox 102.7.0esr versions while testing on Ubuntu 20.4.