WebKit implementation of Async Clipboard counteracts ‘serious security ramifications’ of copy and paste
Web developers using the latest browser version (Safari 13.1) will benefit from “several advantages” that the Async Clipboard API has over the previous API for reading and writing clipboard data via DataTransfer, said Wenson Hsieh, a software developer at Apple, in a post published on the WebKit site on Wednesday (June 23).
The new API introduces two new objects: navigator.clipboard, which contains methods for reading from and writing to the system clipboard, and ClipboardItem, which represents a single item on the system clipboard with multiple potential representations.
But Hsieh acknowledged that “there are serious security ramifications when allowing pages to write data to the clipboard, and privacy ramifications when allowing pages to read from the clipboard.
“Clearly, untrusted web content shouldn’t be capable of extracting sensitive data – such as passwords or addresses – without explicit consent from the user.”
He continues: “Other vulnerabilities are less obvious; for instance, consider a page that writes ‘text/html’ to the pasteboard that contains malicious script. When pasted in another website, this could result in a cross-site scripting attack!”
The perils of copy and paste functionality were highlighted in a recent write-up by security researcher Michał Bentkowski, who netted more than $30,000 in bug bounties after unearthing numerous copy-paste security flaws in web browsers and rich-text editors.
WebKit, the open source web browser engine that underpins Safari, mitigates the potential write vulnerabilities in three ways, explains Hsieh.
“The API is limited to secure contexts, which means that navigator.clipboard is not present for http:// websites”, he said.
In addition, writing to the clipboard must “be triggered during a user gesture”, and both ‘text/html’ and ‘image/png’ data is sanitized before writing to the pasteboard.
Reading restrictions are somewhat stricter “since users may not always be aware that sensitive content has been copied to the pasteboard”, says Hsieh.
“If a page attempts to programmatically read from the pasteboard outside of a user gesture, the promise will immediately reject.
“If the user is explicitly triggering a paste during the gesture (for instance, using a keyboard shortcut on macOS such as ⌘V or pasting using the ‘Paste’ action on the callout bar on iOS), WebKit will allow the page to programmatically read” the clipboard contents.
Hsieh added: “Programmatic clipboard access is also automatically granted” if the system clipboard contents “were written by a page with the same security origin. If neither of the above are true, WebKit will show platform-specific UI which the user may interact with to proceed with a paste.”
Content is also sanitized before being read from the clipboard.
Despite these mitigations, Gareth Heyes, a security researcher at PortSwigger Web Security, the company behind vulnerability testing software Burp Suite and The Daily Swig, believes the Async Clipboard API offers his peers promising terrain for unearthing flaws.
“This looks like a good area to research, as it’s a new feature and the privacy implications of reading the clipboard are substantial,” said Heyes.
According to a 2018 GitHub explainer on the Async Clipboard API by Philip Jägenstedt, the threat of ‘clobbering’ and ‘sniffing’, among other security and privacy risks, had long stymied agreement among browser developers on a universal clipboard API.
This has forced web developers “to rely on alternate methods” such as ZeroClipboard, which is based on Adobe’s ageing Flash platform, widely seen as insecure and set to be blocked outright by all major browsers by the end of the year.
Although the major browser developers recently “converged on support for clipboard access using document.execCommand()”, many inconsistencies remained across implementations, while doubts have been expressed about the API’s long-term sustainability, noted Jägenstedt.