contenteditable

[Mike Stay]

In order to support editors in Caja, we really need contenteditable
mode. Concerns include attached scripts as well as getting
namespacing on ids and styles. We can intercept paste events, but I
don't know to what extent we can modify the content we're being asked
to paste.

Thoughts?
--
Mike Stay - meta...@gmail.com
http://www.cs.auckland.ac.nz/~mike
http://reperiendi.wordpress.com

[Kevin Reid]

On Wed, Nov 14, 2012 at 1:51 PM, Mike Stay <meta...@gmail.com> wrote:
>
> In order to support editors in Caja, we really need contenteditable
> mode. Concerns include attached scripts as well as getting
> namespacing on ids and styles. We can intercept paste events, but I
> don't know to what extent we can modify the content we're being asked
> to paste.
>
> Thoughts?

I haven't actually prototyped this, much less security-tested it, but
what occurs to me is that even if we cannot replace
what-is-being-pasted, we can sanitize it *after* the paste but
*before* the user has a chance to interact with it. This works only if
<script>s etc. don't immediately execute.

But first, we need to consider the threat model. Are we concerned about:

- defending the host page from pasted content, or
- defending the guest from pasted content, or
- defending the host page from abilities granted to the guest by
pasted content (how)?

In particular, an ordinary contenteditable host page would seem to be
vulnerable to the pasted content (unless browsers sanitize/rewrite
pastes — do they?). This is a preexisting risk which the introduction
of Caja does not increase.

If pastes are not malicious, not sanitized, or excluded from the
threat model, then all we need to do is virtualize them for the guest
DOM view, and this is for functionality, not security.

[Mike Stay]

Regarding pasting from the clipboard:
http://stackoverflow.com/questions/3896824/html5-read-the-clipboard/6667108
-----------
Perhaps the HTML5 Core spec doesn't provide an API for accessing the
clipboard, but one of the APIs in the HTML5 family of APIs does. It's
called 'Clipboard API and Events,' and it's currently (as of July
2011) a Working Draft. You can find the spec here:

http://www.w3.org/TR/clipboard-apis/

As for implementations, well, I couldn't find one just yet.
-----------
No, there is no built-in API for accessing the clipboard. BUT you can use
https://github.com/mojombo/clippy
for accessing the clipboard. It's flash not Java, so it should be ok
for you to use. The advantage is it works across all flash-capable
browsers.
-----------



Regarding sanitization:
http://stackoverflow.com/questions/8190770/detect-a-paste-event-in-a-contenteditable
-----------
You can listen for the onPaste event on the div to detect the paste.
If you just want to disable the paste you can call
event.preventDefault() from that listener.

To capture the pasted content however is a little bit more difficult
since the onPaste event does not give you access to the pasted
content. The usual way to handle this is to do the following from the
onPaste event handler:

create a dummy div and place it outside the window boundaries so it's
not visible to visitors
move the focus to this div
call a sanitizer method using a setTimeout(sanitize, 0)
and from your sanitizing method:

find the dummy div and get it's contents
sanitize the HTML and remove the div
move the focus back to the original div
insert the sanitized content in the original div
-----------


https://groups.google.com/d/msg/closure-library-discuss/cDQGNAoGH4o/7KAq5BzsYAoJ
-----------
I've been trying to solve this exact problem of forbidding rich paste :-)

In WebKit, I use contentEditable=plaintext-only

In Firefox, I detect the paste, and then select a display:-moz-deck
zero-width zero-height overflow-hidden div that's a child of the
contentEditable, then I cancel the native paste, and then let the
paste happen there. From there, the contents get extracted and plain
text appears.

In IE, I use: onpaste="document.selection.createRange().text=clipboardData.getData('Text')"

In Firefox, though, you still have a self-XSS attack, where a user can
be tricked into pasting something malicious. However, in Firefox, the
scope of these XSS attacks is that images get loaded, leaking
referers. IE also loads iframes if you let the native paste event
happens -- using a DOM0 handler for onpaste seems to avoid this, while
not popping a security warning. WebKit's plaintext-only is a saviour.
--------------