为什么在 JS 中写入剪贴板被认为是一个安全漏洞？
目前似乎没有纯 JavaScript 方法可以使用大多数现代浏览器访问系统剪贴板，Internet Explorer 是一个例外。关于许多其他 Stack Overflow 问题（例如，使用 Javascript 访问剪贴板 - 没有 Flash？）据解释，此限制是一种故意的安全措施，旨在防止网站从剪贴板读取密码或其他敏感数据。
虽然从剪贴板读取内容显然会带来巨大的安全风险，但我不清楚为什么要写入剪贴板。浏览器通过拒绝 JS 将数据复制到剪贴板的能力来防止什么情况（如果有）？
It seems there is currently no pure JavaScript method for accessing the system clipboard using most modern browsers, Internet Explorer being an exception. On numerous other Stack Overflow questions (e.g., Clipboard access using Javascript - sans Flash?) it's explained that this limitation is a deliberate security measure to protect against web sites reading passwords or other sensitive data from the clipboard.
While it seems obvious that reading from the clipboard would be a huge security risk, it's not clear to me why writing to the clipboard would be. What scenario, if any, are browsers protecting against by denying JS the ability to copy data to the clipboard?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
写入剪贴板是恶意网站（或网站内运行的其他代码，例如基于 Flash 的广告）欺骗用户传播恶意软件的一种方式。这种情况发生在几年前，基于 Flash 的广告将恶意软件 URL 复制到剪贴板上，希望用户在打算粘贴其他内容时粘贴它，从而污染 Facebook 帖子、论坛和电子邮件等内容。您可以粘贴指向某些路过恶意软件的链接，而不是指向蒂莉阿姨的猫的照片的链接。通常，这些都是“您已感染病毒，请支付 50 美元购买删除软件”的虚假防病毒骗局。
我对此做了一些研究，因为我的许多 ClipMate 客户都在问为什么这些令人讨厌的 URL 突然出现在 ClipMate 中。在研究过程中，我受到了 MSNBC 和 DIGG 上基于 Flash 的广告的攻击。剪贴板随后在 Flash 10 中被锁定。您可以在此处阅读有关我的传奇的更多信息：http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous
我希望JavaScript 的限制是为了防止类似的事情发生。
Writing to the clipboard is a way for malicious web sites (or other code running within sites, such as flash-based ads) to trick users into spreading malware. This happened a few years ago with flash-based ads that copied a malware URL onto the clipboard, in hopes that users would paste it when they intended to paste something else, thus polluting things like facebook posts, forums, and e-mail. Instead of a link to a photo of Aunt Tilly's cat, you'd paste a link to some drive-by malware. Typically these were the "you've been infected with a virus, pay us $50 for the removal software" fake antivirus scams.
I did some research on it, as a lot of my ClipMate customers were asking why these nasty URLs were suddenly appearing in ClipMate. While researching, I was attacked by flash-based ads on MSNBC and DIGG. The clipboard has been subsequently locked down in Flash 10. You can read more about my saga here: http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous
I expect that the JavaScript restriction is to prevent similar things from happening.
如果用户不希望他或她的剪贴板被覆盖怎么办？
What if the user doesn't want his or her clipboard overwritten?
如果用户期望他们的剪贴板包含一个东西，但它被秘密地替换为另一个东西，即使这是一个潜在的安全问题，而不仅仅是一个烦恼。
虽然不太可能是攻击媒介，但认为可以想象出涉及社会工程的东西并非没有道理：说服用户将秘密更改的信息粘贴到目标资源上的密码字段中。然后，该资源将通过攻击者已知的密码来保护。
If the user expects that their clipboard contains one thing, but covertly it's been replaced by another thing, even that's a potential security problem, not just an annoyance.
Although an unlikely attack vector, it's not unreasonable to think something could be dreamed up that involves social engineering: convince the user to paste covertly altered information into a password field on a target resource. That resource would then be secured by a password known to the attacker.
除了上述漏洞问题之外，至少在一种情况下，JavaScript 剪贴板 API 的不当实现可能会引发一些安全问题。
如今，我们有了新的 API，可以在不同的窗口之间建立连接，而无需调用服务器端，例如 postMessage、MessageChannel 或者，BroadcastChannel 最近引入了 Firefox。这些 API 具有不同级别的浏览器支持，但都考虑了跨源问题。也就是说，除非该窗口实际上明确允许，否则不可能从不同主机上的窗口接收消息。
这不适用于剪贴板 API。想象一下页面上的某些代码将代码粘贴到剪贴板，并且该剪贴板被另一个窗口扫描。
这是一些非常奇怪和高度假设的场景，取决于一些非常奇怪和奇异的假设，但值得一提。
Aside from abovementioned vulnerability issues there's at least one scenario where imporper implemetation of javascript clipboard API can raise some security concerns.
Nowadays we have new APIs for establishing connection between separate windows without invoking server-side, like postMessage, MessageChannel or, say, BroadcastChannel recently introduced to Firefox. These APIs has different level of browser support but all of them are considering cross-origin issues. That is, it should be impossible to recieve a message from a window on a different host unless this window actually explicitely allows it.
This doesn't hold with clipboard API. Imagine that some code on the page pastes code to clipboard and this clipboard is scanned by some another window.
This is some very strange and highly hypotetical scenario depending on some quite strange and exotic assumptions, but it worth to mention it.