User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce: I noticed that the screenshot iframes inserted in web can have their CSS changed. By setting their style attribute we can override all its styles. I then noticed that we can take a screenshot of entire website (even things outside its visible body). Finally, I noticed the screenshot preview is data uri which contains all of the data of the screenshot conveniently in base64. Combining all of the above I think I came up with a pretty convincing PoC. Video of it in action: https://www.youtube.com/watch?v=De--NcpZofM (note: in the video I use 0.5 opacity for your clarity, it can be lowered to 0 for full effect) Actual results: Screenshot of cross origin website is taken unbeknownst to the user, as well as the data grabbed for said screenshot. Expected results: I think the simplest solution is to serve the screenshot preview through blob: URI. Then all you are left with is a cross origin blob url which can't be read from any normal web content.

the helper file required to grab the DnD object. Please host both this and original PoC in the same folder.

Jared, can you or other folks on the screenshots team take a look?

Would like to add that even if the preview is changed to blob url, we can still clickjack to the point of having a user later paste the image saved to clipboard. Though that would be less convincing since a notification appears when you choose to copy screenshot. That will alarm more people than original PoC but still something to consider. Not sure if it's too much to ask to keep checking iframes' style attribute?

I think the plan is to take the UI out of the document entirely, but I defer to Jared and/or other screenshots folks to update the bug with more details (and/or mark as dupe).

This bug is a different way of saying it, but effectively is a duplicate of bug 1389707 -- or at least will be fixed by the same fix (bug 1340930).

The ability to muck with the screenshot CSS is known, but reading cross-origin data from the resulting screenshot is a clever twist. Not sure that makes it a different bug but for now I won't dupe it. Changing the results from data: to blob as suggested could be done independently of creating a secure overlay API (and probably much easier).

Ian filed https://github.com/mozilla-services/screenshots/issues/3508 and has done some work on it. We should move it into the next sprint.

Although a blob url is being used now, the origin of said blob is same as the potential attacker website and not the webextensions. Attached PoC requires the old dnd.html helper. WE still end up with base64 data of cross origin website. A fix would require the blob url to have the origin of the extension, and add this url to the manifest file as web content so they are viewable but unreadable.