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

Hello Hallvord,

> Hallvord Reiar Michaelsen Steen <mailto:hsteen@mozilla.com>
> 27 août 2015 18:32
> On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht <paul@hoplahup.net
> <mailto:paul@hoplahup.net>> wrote:
>
>     do you not want to split the writable types list in safe and
>     non-safe ones and let browsers how they deal with unsafe ones? 
>
>
> No, absolutely not. If we leave such things up to the browser we end
> up with implementations that do wildly different things and web
> developers suffering new levels of incompatibility pain.
I mean, let them decide if they support it or not.
>
>     Here's an idea:
>
>     html, xml, and picture formats should be in the unsafe ones. 
>
>
> If we can help it, HTML should not be unsafe. It's the web's primary
> format, and if we class it as unsafe we basically prohibit scripts
> from being able to export formatted text to the clipboard.
>
> I do however know it takes a bit of a leap of faith to believe that
> it's safe enough, given that HTML parsing was a bit of a dark art for
> many years. Today we can at least hope a lot of software that consumes
> HTML has been updated to use HTML5 algorithms.
HTML5 has changed the parsing algorithm indeed.
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
when pasting from a web-page (I believe "save as web page complete" also
does a part of that).

>  
>
>     I guess json too (but both XML and JSON are too generic to my taste).
>
>
> Why should JSON be unsafe? Parsing JSON should be pretty easy, so
> hopefully most parsers would be safe.
I think the danger lies beyond parsers.
In XML, you would have XInclude which can be used in many tools to
include content from outside.
I believe I have seen JSON syntaxes that had external references as part
of their specs but I can't remember which now.
As long these formats are copied as is and parsed blindly the risk of
external inclusion remains.

However, it is true that I do not know of applications that receive
application/xml or text/json without being web-aware or even developer
aware... I am not sure what to suggest here.
(sniffing xml or json in the plain text is commonly done in many apps is
actually much worse in terms o security).
>  
>
>     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).
>
>
> On Windows I believe images are transcoded to and from DIB - device
> independent bitmap format anyway. Is there any equivalent graphics
> interchange format on other platforms? Does mandating such transcoding
> help guarantee against payloads that might trigger vulnerabilities in
> target software?
All platforms I know of have some sort of transcoding of pictures (in
Macs it is PDF as the central format).
I think this is a very safe mechanism to rely on.
> I expect it adds a significant hurdle against exploits, but I'd like
> input from Daniel Cheng and perhaps from people who have worked on
> image decoders..
> -Hallvord
Yes, comments would be helpful.

paul