1727176 - When fission is enabled, a cross-domain subframe drag/drop can be done occur on the parent frame.

Status: RESOLVED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Neil Deakin]

Bug 605991 added a check so that a drag and drop started in a subframe from a different host and dropped in the parent frame would not return any data. This check does not work in fission, because it uses the source document in nsContentUtils::CheckForSubFrameDrop which is null.

There is a similar issue with editor (for example , textareas) which allows dropping of text from a different host in a subframe.

Marking as security sensitive for now as the original bug was sg:moderate.

Comment 1

[Neil Deakin]

Attachment: Bug 1727176, use window contexts for the drag and drop source, r=smaug

Comment 2

[Neil Deakin]

Attachment: Bug 1727176, remove unused source document arguments from html editor, r=masayuki

Depends on D123520

Comment 3

[Neil Deakin]

Attachment: Bug 1727176, use the principal to determine the source of the drag, r=masayuki

Depends on D123521

Comment 4

[Neil Deakin]

The first part fixes this in general. The second part is some cleanup needed for part 3, which fixes this for editable areas.

Comment 5

[Neil Deakin]

Attachment: testcase

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

use window contexts for the drag and drop source, r=smaug
https://hg.mozilla.org/integration/autoland/rev/b414381c4e256133c3d380e9bfef82d8d44ebb27
remove unused source document arguments from html editor, r=masayuki
https://hg.mozilla.org/integration/autoland/rev/200bd6fb18769553de206994b74eb09e78ea4d5c
use the principal to determine the source of the drag, r=masayuki
https://hg.mozilla.org/integration/autoland/rev/4fb35eee2ac369b3b09f95625f4c7a4198f1e524

https://hg.mozilla.org/mozilla-central/rev/b414381c4e25
https://hg.mozilla.org/mozilla-central/rev/200bd6fb1876
https://hg.mozilla.org/mozilla-central/rev/4fb35eee2ac3

Comment 7

[Daniel Veditz [:dveditz]]

After the fix, this testcase (and probably the older bug -- I never verified that one) still leaks the types of clipboard data associated with the selection, which varies depending on what you drag. Technically this is still cross-origin information leaking.

Most content will be made up of similar mixes of things so it's not leaking much, but you could probably contrive some testcase where you frame some target site and expose a small window onto a particular area that changes type (avatar image if logged in, login button if not?), and come up with some excuse to have the user drag it (probably transparent, thinking they're dragging something else).

Pretty damned contrived to get one or two bits of information.