Re: paste events and HTML support - interest in exposing a DOM tree?

On Tue, 03 May 2011 07:10:10 +0900, João Eiras <joao.eiras@gmail.com>  
wrote:

>> event.clipboardData.getDocumentFragment()
>>
>> which would return a parsed and when applicable sanitized view of any
>> markup the implementation supports from the clipboard.

> This is already covered by doing  
> x=createElement;x.innerHTML=foo;traverse x

Of course it is. The point was simply to see if there was interest in  
possibly optimising away an extra serialize->parse roundtrip, if  
developers feel it would be more convenient to get the DOM right away  
rather than the markup.

> Regarding simplifying the pasted html to remove stuff that could be  
> malicious, consider a rogue app that injects a script in the clipboard  
> and expects the user to hit paste on his bank site.

Well, I've never seen a bank site with a rich text editor /  
contentEditable-based feature customers are meant to use ;-)

Rouge scripts and social engineering to paste them in the comment field on  
Facebook is still a threat to worry about. If the implementation knows  
that the content originates from another website it should definitely be  
sanitized. I don't think it adds much security to sanitise content from a  
local application though - an application running locally already has  
quite a lot of possibilities, for example to tell the browser to launch a  
javascript: URL directly or go into the DOM to modify things through the  
browser's accessibility APIs. Using social engineering to make the user  
paste something would be an awkward way to try to launch an exploit, no?

> There is little the user agent can do but to provide quick and easy  
> methods to sanatize this. There is already the toStaticHTML API that IE  
> implements.

I'm planning to *not* leave sanitization to the script author, but have it  
as a default and (currently) non-overridable mode for cross-origin HTML  
paste. So the user-agent will do it all behind the scenes before the  
script event gets to see a single tag of the markup.

> I would suggest supporting and implementing it. Or even add a sister  
> property of innerHTML, innerStaticHTML which would not return scripts or  
> event handlers on reading, and would parse out those when setting.

That sounds like a good idea, but would be best followed up in a separate  
context.

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Tuesday, 3 May 2011 10:20:23 UTC