- From: FrederickDoering <notifications@github.com>
- Date: Mon, 27 Jul 2015 10:38:18 -0700
- To: w3c/clipboard-apis <clipboard-apis@noreply.github.com>
- Message-ID: <w3c/clipboard-apis/issues/9/125282894@github.com>
@hallvors Thanks. I'm disappointed but I can't say I'm surprised that windows allows a form of code execution from CBF_DATA. I can see how the ability to **write** to the clipboard can be dangerous even for formats that one might initially assume are benign like RTF. However, I believe this proposal would work for **reading** from the native clipboard and writing to a private, in browser only, clipboard. That way, pages that want to co-operate and use the same mime-type can register formats and have the clipboard work as expected. And pages could even receive data from native applications, but would only be able to write to the native clipboard a very limited set of things (text/plain, text/html, etc.). I think to eliminate any security concerns with writing to the clipboard, for each format, the following steps would have to be taken: 1. Verify that the there are no known intentional or unintentional ways of exploiting that format assuming the payload is properly formed. (very difficult) 2. every time that format is written to, verify that the payload is properly formed. (not as difficult, though possibly still awful depending on the format) I believe the first step has already been taken for the "required" mime-types, but the second step has not yet been implemented and there was a suggestion to remove some of the mime-types from the required list as a solution to eliminate exploits from malformed payloads. In conclusion, I don't see a security risk from **reading** arbitrary formats from the native clipboard, and for **writing** to the native clipboard I see the need to verify the payloads are well formed, which cannot be done for arbitrary formats, but should be done for all formats that support writing. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/clipboard-apis/issues/9#issuecomment-125282894
Received on Monday, 27 July 2015 17:39:14 UTC