On Wed, Nov 14, 2012 at 1:51 PM, Mike Stay <[email protected]> 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.
