Re: Clipboard API: remove dangerous formats from mandatory data types

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem

I'm trying to handle this question on another E-mail thread so please
follow up there :)

>> JSON: nope, there's no such thing as "external inclusion" in JSON, and
>> there never will be.

> You can certainly exchange a Bookmark-list over json (e.g.
> http://kb.mozillazine.org/Bookmarks)... that would be a simple example of
> some JSON whose URLs you should not "GET" without some concerns (e.g.
> localhost servers).

But JSON as such has no concept of "URL" or a "URL" data type. To a
JSON implementation it's just a string, and I don't see any step of a
clipboard roundtrip doing anything magic to figure out what strings
are URLs or trying to process them :).

> Similarly XInclude-enabled XMLs or even other remote-including-XMLs (e.g.
> through DTD) should ask the users, deny, or inline.

Do you think we should not mandate support for writing XML to the
clipboard from JS, then?
Is this also a problem for MathML?

> For the unsafe formats, the warning could say that the UA-implementors
> should only support the flavour if they have a method to make this content
> safe so that local applications (which do not expect untrusted content)
> receive content they can trust when pasting. Methods to make the content
> safe include the following: transcoding a picture, inlining all external
> entities for html, xml, mathml, or rtf).

To make sure we understand each other: what you're saying here is that
if I do this in a JavaScript:

document.oncopy = function(e){
  e.clipboardData.setData('text/html', '<img
src="https://mozilla.org/images/logo.gif">');
  e.preventDefault();
}

the data that actually ends up being written to the clipboard will be

<img src="data:image/gif;base64,[Mozilla's logo data: encoded]">

I think that would be rather surprising behaviour, and would create
some attack scenarios if the attacker can predict the URLs of images
with private data inside them. On pasting they would then be data:
URLs without a concept of origin, the UA would no longer be able to
rely on mechanisms like CORS and/or session data to determine if it's
OK to show the image. If that image would be painted on a CANVAS after
pasting, the image data would now be accessible to JS without
tainting..

Is this really what you propose? :)

> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> helpfully adds a "public.tiff" clipboard entry with the same random
> data). There's no transcoding or similar.
>
> Please share the test, this is exactly the kind of things we need around to
> see how crooked one could touch upon.

I was playing around with the code the reporter of
https://bugzilla.mozilla.org/show_bug.cgi?id=860857 submitted - here's
an online version modified to also put image/tiff on the clipboard:
https://jsfiddle.net/gk3vm5L8/1/ (apparently this test was derived
from some Google Docs code).

>> So, the question (for recap) is: would it be OK to let JS write binary
>> data labelled as an image type if the browser was required to
>> transcode it to TIFF or DIB and only update the clipboard if such
>> transcoding succeeded?

> My answer is definitely yes as we should*assume that image transcoders
> should remove the dangers of flawed parsers as they could happen otherwise
> in other situations (e.g. in doing screenshots).

Implementors? Can we rescue clipboardData.items.add(binaryImageData,
'image/jpeg') by mandating transcoding? :)
Is the current Safari Mac behaviour a problem or is it safe enough to spec?
-Hallvord

Received on Tuesday, 9 February 2016 11:58:25 UTC