1352840 - Cross-origin data theft using drag and drop from iframe.

Status: RESOLVED FIXED

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

Description

[Abdulrahman Alqabandi]

Attachment: iframe.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce:

Looks like a bypass of the fix implemented in Bug 605991.

PoC attached.


Actual results:

If we remove an iframe after dragging content from it, we can bypass the same-origin checks.


Expected results:

If you remove the call to remove the iframe, we can see the desired behavior. (ln 16)

Comment 1

[Abdulrahman Alqabandi]

I tested this on latest nightly (with and without e10s) and stable and it looks like it works on both.

Comment 2

[Nika Layzell [:nika] (ni? for response)]

I don't know very much about how the cross origin subframe drop checks work. I think neil will understand what's going on here the best.

Comment 3

[Neil Deakin]

I think to fix this we would need to check for a subframe (nsContentUtils::CheckForSubFrameDrop) during dragover and remember this state for later use by the drop event.

Comment 4

[Abdulrahman Alqabandi]

May I get an update on this bug, please?

Comment 5

[Daniel Veditz [:dveditz]]

I think comment 4 is for Neil

Comment 6

[Tom Ritter [:tjr]]

Gijs recently fixed Bug 1322864 so I'm going to redirect the ni to him.

Comment 7

[:Gijs (he/him)]

I don't really have cycles to pick this up in the near future, and am really not super familiar with our drag/drop code - the work in bug 1322864 turned out to be a trivial generalization of existing code, and this doesn't look like that off-hand. I can keep the needinfo in case I find time but if you were hoping to find an assignee I think pinging Neil or someone else is a better bet. Tom, pinging you back to ensure this doesn't inadvertently fall down the cracks...

Comment 8

[Tom Ritter [:tjr]]

While we would like to burn down our backlog of moderates, we haven't put serious effort into triaging them, so I am comfortable waiting for that triage to happen next year and try to find assignees during it.

Comment 9

[Neil Deakin]

This should have been fixed by 1646513 and 1727176.