- From: FrederickDoering <notifications@github.com>
- Date: Thu, 23 Jul 2015 07:50:41 -0700
- To: w3c/clipboard-apis <clipboard-apis@noreply.github.com>
- Message-ID: <w3c/clipboard-apis/issues/9/124130353@github.com>
@hallvors Yes, your explanation covers the general idea. Details like conflicts, ordering, and scope of map are irrelevant to the native application safety. While I can see that there would indeed be potential for a native app to be exploitable through pasting arbitrary data to it, I don't see that excluding "binary" data would grant much if any additional protection. The data on the windows clipboard is all just bytes. So writing a "string" to the clipboard still just results in the bytes of the string being written to the clipboard. Unless there's a filter that doesn't allow certain characters like null, or backspace, the ability to write binary data grants no additional capabilities then was already possible. That said, I hadn't considered the possibility of exploiting native apps in my security considerations. So I'll need to think about that some more, but here are some of my initial thoughts: I believe current clipboard support already allows arbitrary data to be put on the clipboard under the text/plain format. However, applications are expecting there to be arbitrary data on that format and thus will hopefully already be hardened against attacks through that channel. The same cannot be said for formats that are used primarily by one vendor. Fro example the windows clipboard handle `Biff12` is used by Excel, and Excel might only be expecting valid formatting when pasting from `Biff12` so if excel wsa programmed poorly it might be possible to place something on `Biff12` so then when it's pasted into excel, you can do something malicious. While this exploit is already available to any other native app on the computer, it's much harder to get a malicious native app then to copy something from a malicious (or just insecure and therefor unintentionally malicious) website and paste it into excel (or any other exploitable native app). Thus allowing writing to the clipboard to arbitrary formats increases the exposure of user. I think this is a good argument for requiring permissions for this capability. Do you have a reference for the "pushback" you mentioned so I can inform myself further on this matter? --- Reply to this email directly or view it on GitHub: https://github.com/w3c/clipboard-apis/issues/9#issuecomment-124130353
Received on Thursday, 23 July 2015 14:51:16 UTC