Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Fri, 10 Feb 2012 01:24:05 +0100, Ian Hickson i...@hixie.ch wrote: We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? This is a good question. Presumably the scenario is that hostile page A provides some content and gets the user to select and copy or drag it to page B's contentEditable region, including any script in the selection, which once pasted becomes a cross-site scripting vulnerability. That might be one threat model, but it's one that UAs are already handling. Most UAs remove or plan to remove SCRIPT tags from pasted HTML data. I've mentioned this in the drag-and-drop spec. Goo idea. Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? Finally, regarding the topic this E-mail's subject is dealing with, I've spec'ed this: implementation should use clipboard content sequence number on platforms where this is available, creativity elsewhere, to make sure script can only access one single clipboard entry. I've also added a test for this. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote: Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) Well presumably all the URLs should be made absolute in the copy/drag code, not the paste/drop code. The paste/drop code has no context. No parsing needed for that though, the URLs are already resolved in the DOM so it's just a matter of serialising them. * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources How would you distinguish this case from a hostile app tricking the user into copying HTML that has pointers to sensitive local files? * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful I wouldn't do this via parsing, but DOM filtering. That's the semantic layer. A whitelist DOM filter will ensure that only the stuff the browser thinks is safe can get through. So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? I guess we could say that HTML dragged from the page could have URLs absoluted in the serialisation. The other stuff doesn't seem necessary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
This discussion seems to raise the issue of what happens to URLs to images (or other embedded objects) that are unresolved but become resolved when pasted. E.g. file:///Users/anton/Library/AddressBook (if that ever made sense) Should these also be sanitized away so that they do not, suddenly become attempted? Paul Le 10 févr. 2012 à 22:36, Ian Hickson a écrit : On Fri, 10 Feb 2012, Hallvord R. M. Steen wrote: Now, I don't think that was the question Daniel Cheng was asking. If you look at the HTML/XHTML specific instructions for the paste event (in the processing model section: http://dev.w3.org/2006/webapi/clipops/#processing-model ) you'll see that it specifies quite a bit of parsing and such. The goals are: * Resolve URLs and links - the page script won't know the base URI to resolve against (on Windows this is in the CF_HTML format's meta data and the page script doesn't get access to it) Well presumably all the URLs should be made absolute in the copy/drag code, not the paste/drop code. The paste/drop code has no context. No parsing needed for that though, the URLs are already resolved in the DOM so it's just a matter of serialising them. * Make it possible to paste HTML from a local application that embeds local resources (img src=file://..) and enable page scripts to process and upload said resources How would you distinguish this case from a hostile app tricking the user into copying HTML that has pointers to sensitive local files? * Optionally do extra privacy or security-related filtering if the UA implementor considers it useful I wouldn't do this via parsing, but DOM filtering. That's the semantic layer. A whitelist DOM filter will ensure that only the stuff the browser thinks is safe can get through. So, I think the question Daniel is asking, is: why don't we process URLs and local resources this way if HTML data is drag-and-dropped to a page? Should this processing be moved to the DnD spec? I guess we could say that HTML dragged from the page could have URLs absoluted in the serialisation. The other stuff doesn't seem necessary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011, Daniel Cheng wrote: On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote: Not 100% sure what you mean by concerns - do you mean for example if I drag a selection that embeds local images from my local word processing application to an online editor? I don't know how/if DnD handles this use case. CCing Ian. We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? Presumably the scenario is that hostile page A provides some content and gets the user to select and copy or drag it to page B's contentEditable region, including any script in the selection, which once pasted becomes a cross-site scripting vulnerability. As far as I see it, the right way to solve this is for dragging, copying, dropping, and pasting of HTML to filter the DOM using a whitelist. It's not clear to me that this needs to be done in an interoperable way. I've mentioned this in the drag-and-drop spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 09:43:33 +0900, João Eiras joao.ei...@gmail.com
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to access the clipboard contents. Or does
execCommand dispatch a synchronous event ?
Yes, it does. See
http://dev.w3.org/2006/webapi/clipops/clipops.html#integration-with-other-scripts-and-events
I expect implementations to let users configure if a site/app is allowed
to use execCommand for cut/copy/paste, perhaps with a prompt on first use.
What if the event is prevented ? Does execCommand return false ?
I don't know much about what execCommand is meant to return, but e.g.
doing execCommand('copy') and then event.preventDefault() from a 'copy'
event listener is intended to prevent copying.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. To handle the getData case, I've thought of adding a proxy clipboard per browsing context. Read operations read from the proxy clipboard, write operations write to the proxy and system clipboards. User initiated actions like dropping, or pasting would update the proxy clipboard with the system clipboard contents, prior to the event being dispatched on the webpage. I *think* that is a good strategy. paul
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote: Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. There are too many web apps with a Copy this to clipboard button, like dropbox. If a proxy clipboard is implemented, as I explained, then the privacy concerns are mostly handled.
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, May 19, 2011 at 04:01, João Eiras joao.ei...@gmail.com wrote: On Thu, May 19, 2011 at 7:43 AM, Paul Libbrecht p...@hoplahup.net wrote: Le 19 mai 2011 à 02:11, João Eiras a écrit : getData and setData must work outside clipboard events, like when clicking paste/copy/cut buttons on a toolbar. The clipboardData object needs to be exposed on the window, like in IE. I fully disagree here. This is exactly what has made the CnP API of MSIE a plague with a very bad press coverage. getData and setData can only be used within the event processing which must be triggered by the user-agent at a user-recognizable invocation of the copy/cut or paste command. That some browsers allow differently for trusted sites is ok to me but should not be an essential focus of this spec I find. There are too many web apps with a Copy this to clipboard button, like dropbox. If a proxy clipboard is implemented, as I explained, then the privacy concerns are mostly handled. To me, this sounds like an implementation detail. There are reasons why a UA wouldn't want to pull the contents of the system clipboard into the proxy clipboard. Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, May 17, 2011 at 22:07, Hallvord R. M. Steen hallv...@opera.comwrote:
Should our implementation work harder to keep what we promise in
clipboardData.items, or should we be content that such timing issues will be
so rare that throwing is fine? After all, most applications manipulate the
clipboard only in response to user input, which is a pretty modal source of
events, and by definition the paste event will fire in response to user
input within the document..
I think it's fine to simply throw as this typically happens in response to a
user action.
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if the
script calls getData('text/html') within the paste event thread. Implementor
feedback welcome!
Ideally we shouldn't manipulate any data until it's been requested by the
page, since reading data off the clipboard is a potentially slow operation.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011 15:49:33 +0900, Daniel Cheng dch...@chromium.org
wrote:
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the script calls getData('text/html') within the paste event thread.
Implementor feedback welcome!
Ideally we shouldn't manipulate any data until it's been requested by
the page, since reading data off the clipboard is a potentially slow
operation.
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-data
to where we prepare the paste event, because integrating this into the
HTML5 DataTransfer stuff becomes much easier this way. (Previously I
spec'ed it so that this work would happen on a script calling
getData('text/html') but that would require some hacking around with the
getData() definition in HTML5.) This means we read and process the HTML
part from the clipboard before firing paste, but any binary/embedded data
will only be read on demand.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 02:16, Hallvord R. M. Steen hallv...@opera.comwrote:
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
where we prepare the paste event, because integrating this into the HTML5
DataTransfer stuff becomes much easier this way. (Previously I spec'ed it so
that this work would happen on a script calling getData('text/html') but
that would require some hacking around with the getData() definition in
HTML5.) This means we read and process the HTML part from the clipboard
before firing paste, but any binary/embedded data will only be read on
demand.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Shouldn't we have similar concerns about the text/html content of a drop?
Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng dch...@chromium.org
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
Ideally we shouldn't manipulate any data until it's been requested by
the
page, since reading data off the clipboard is a potentially slow
operation.
What do you think about the current spec text? I've moved the section
http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model-for-pasting-html-datato
where we prepare the paste event, because integrating this into the
HTML5
DataTransfer stuff becomes much easier this way. (Previously I spec'ed
it so
that this work would happen on a script calling getData('text/html') but
that would require some hacking around with the getData() definition in
HTML5.) This means we read and process the HTML part from the clipboard
before firing paste, but any binary/embedded data will only be read on
demand.
Shouldn't we have similar concerns about the text/html content of a drop?
Not 100% sure what you mean by concerns - do you mean for example if I
drag a selection that embeds local images from my local word processing
application to an online editor? I don't know how/if DnD handles this use
case. CCing Ian.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 19 May 2011 03:12:41 +0900, Daniel Cheng dch...@chromium.org
wrote:
[Added back a bit more context since I add Ian to CC]
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if
the
script calls getData('text/html') within the paste event thread.
getData and setData must work outside clipboard events, like when clicking
paste/copy/cut buttons on a toolbar. The clipboardData object needs to be
exposed on the window, like in IE.
To handle the getData case, I've thought of adding a proxy clipboard per
browsing context. Read operations read from the proxy clipboard, write
operations write to the proxy and system clipboards. User initiated actions
like dropping, or pasting would update the proxy clipboard with the system
clipboard contents, prior to the event being dispatched on the webpage.
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Thu, 19 May 2011 09:11:56 +0900, João Eiras joao.ei...@gmail.com
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On , Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 19 May 2011 09:11:56 +0900, João Eiras joao.ei...@gmail.com
wrote:
getData and setData must work outside clipboard events, like when
clicking paste/copy/cut buttons on a toolbar.
I think this is covered by execCommand('Paste') etc.
But there is no way to access the clipboard contents. Or does execCommand
dispatch a synchronous event ? What if the event is prevented ? Does
execCommand return false ?
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 5:43 PM, João Eiras joao.ei...@gmail.com wrote: But there is no way to access the clipboard contents. Or does execCommand dispatch a synchronous event ? It fires copy/paste events. - Ryosuke
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote: Not 100% sure what you mean by concerns - do you mean for example if I drag a selection that embeds local images from my local word processing application to an online editor? I don't know how/if DnD handles this use case. CCing Ian. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng dch...@chromium.org wrote: I believe this problem is solvable without a spec change. OK. I'd like to put in some non-normative warning or note about this problem though. On Windows and Mac, implementations can use a native clipboard sequence number to determine the contents of the clipboard have changed. Interesting. What, in your view, should the implementation do if it discovers the contents has changed while a paste event thread is running? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Tue, May 17, 2011 at 14:03, Hallvord R. M. Steen hallv...@opera.comwrote: On Tue, 17 May 2011 15:30:08 +0900, Daniel Cheng dch...@chromium.org wrote: I believe this problem is solvable without a spec change. OK. I'd like to put in some non-normative warning or note about this problem though. On Windows and Mac, implementations can use a native clipboard sequence number to determine the contents of the clipboard have changed. Interesting. What, in your view, should the implementation do if it discovers the contents has changed while a paste event thread is running? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ Safari returns an empty string from getData() if this happens. If the caller is using event.clipboardData.items, maybe throw a DOM exception when getAs*() is called. Daniel
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011 08:14:42 +0900, Daniel Cheng dch...@chromium.org
wrote:
Interesting. What, in your view, should the implementation do if it
discovers the contents has changed while a paste event thread is
running?
Safari returns an empty string from getData() if this happens. If the
caller
is using event.clipboardData.items, maybe throw a DOM exception when
getAs*() is called.
We have a problem indeed if we neither want to copy the data from the
clipboard nor lock it while the script is processing the paste event: If
we give the script a nicely prepared DataTransferItems list and the stuff
we've promised is no longer on the clipboard when the script tries to use
it, because another application overwrote it..
Should our implementation work harder to keep what we promise in
clipboardData.items, or should we be content that such timing issues will
be so rare that throwing is fine? After all, most applications manipulate
the clipboard only in response to user input, which is a pretty modal
source of events, and by definition the paste event will fire in response
to user input within the document..
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if the
script calls getData('text/html') within the paste event thread.
Implementor feedback welcome!
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
IMO getData() should be 'live' - i.e. return what's on the clipboard. I think having it return live data could result in potential security issues. Couldn't a script loop inside the paste event to keep sniffing out live data? What should we do about this? Should the spec mandate a timeout or a limit on how many times a script may call getData() for the same event? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
