[whatwg] Should scripts and plugins in contenteditable content be enabled or disabled?

[Ian Hickson]

On Fri, 23 Apr 2010, Simon Pieters wrote:
> On Fri, 23 Apr 2010 01:28:47 +0200, Robert O'Callahan wrote:
> > 
> > See https://bugzilla.mozilla.org/show_bug.cgi?id=519928
> > 
> > Suppose we have a <script> element inside a contenteditable parent. 
> > Should the script run? What about on* attribute event handlers, should 
> > they fire in response to events? What about <object> plugins inside a 
> > contenteditable parent, should they be instantiated?
> > 
> > In Webkit, scripts, event handlers and plugins run normally. IE 
> > disables them. Gecko disables them when designmode is used but enables 
> > them for contenteditable. In 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=519928#c46a CKEditor 
> > developer argues forcefully that we should disable them.
> > 
> > If we do choose to disable them, exactly how this should be specced is 
> > not completely clear to me.
> > 
> > There is a side issue of how editable <iframe>s should be treated. 
> > Presumably we should load the subdocument, but if we disabled scripts 
> > for editable content, should we allow scripts to run inside the 
> > <iframe> document? Probably yes to allow framebusting to run. Perhaps 
> > we should prevent user events from being delivered to the <iframe> 
> > document though?
> 
> I think scripts, event handlers and plugins should run normally in 
> contenteditable. Opera have tried hard to reverse engineer and implement 
> the script disabling behavior for designMode in IE and Mozilla, but 
> really I think it would be saner if we let scripts, event handlers and 
> plugins run normally in designMode as well.
> 
> http://lists.w3.org/Archives/Public/public-html/2007Nov/0218.html
> http://lists.w3.org/Archives/Public/public-html/2008Mar/0038.html
> 
> (We might have changed behavior again slightly for compat with some 
> sites, I don't recall the details.)
> 
> It seems Hixie has decided to go back to the WebKit behavior in the spec 
> for designMode.
>
> http://html5.org/tools/web-apps-tracker?from=2817&to=2818

On Fri, 23 Apr 2010, Simon Pieters wrote:
>
> Apparently the details are as follows:
> 
> [[
> pre-included scripts run -
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/456 (same as
> before afaict, but unlike Gecko)
> inserted scripts do not run -
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/457
> eventlisteners work -
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/458 (new behavior,
> this was what broke Y!Mail, ebay, baidu)
> on* attributes do not work -
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/459 (same as
> before)
> ]]

On Fri, 23 Apr 2010, Robert O'Callahan wrote:
> 
> It's certainly the easiest to implement, but you can see feedback in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928 that this makes life 
> difficult for people writing editors.

On Tue, 18 May 2010, Ojan Vafai wrote:
> 
> The webkit behavior of allowing all scripts makes the most sense to me. 
> It should be possible to disable scripts, but that capability shouldn't 
> be tied to editability. The clean solution for the CKEditor developer is 
> to use a sandboxed iframe.
> 
> I don't see a security benefit for disabling script as you'd have all 
> the same issues with loading any user-content in a non-editable area. 
> The only catch is that you *do* need to disable script from pasted and 
> drag-dropped content (see http://trac.webkit.org/changeset/53442). 
> Basically, any site serving user-content will already need to mitigate 
> XSS some other way, so disabling script in editable areas is not 
> necessary, but paste/drag-drop can't reasonably rely on server-side 
> solutions, so must be done by the UA.
> 
> Putting my developer hat on, trying to make Google Gadgets work in 
> Google's rich text editor inside Firefox designMode was awful due to 
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928. A large percentage 
> of Google Gadgets load as iframes and require javascript onload. We had 
> to play tricks with turning off designMode, appending the iframe and 
> turning designMode back on. It was an awful solution that never worked 
> very well.

On Wed, 19 May 2010, Robert O'Callahan wrote:
> 
> That makes sense to me. I'll see what the other editor developers think.

On Thu, 20 May 2010, Robert O'Callahan wrote:
> 
> Discussion led to the point that there's a fundamental conflict between 
> sandboxed iframes and JS-based framebusting techniques. The point of 
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928 is that Web sites 
> using JS-based techniques to prevent clickjacking can be thwarted if the 
> containing page has a way to disable JS in the child document. Currently 
> 'designmode' is usable that way in Gecko, but 'sandbox' would work even 
> better.
> 
> Maybe sites should all move to declarative techniques such as CSP or 
> X-Frame-Options (although there are suggestions that maybe they don't 
> want to for some reason --- see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928#c5 ). But there are 
> still issues with existing sites. Should we care?

On Wed, 19 May 2010, Adam Barth wrote:
> 
> Virtually none of the JavaScript framebusting scripts used by web sites 
> are effective.  You can build one that is effective, but you need to 
> build it with the idea that JavaScript might be disabled, and, in that 
> case, it will play nice with @sandbox.  I'd recommend that sites use 
> something declarative, such as X-Frame-Options or 
> Content-Security-Policy.

On Wed, 19 May 2010, Collin Jackson wrote:
> 
> Yes. If anyone would like to see more evidence of this, here's a recent 
> study of the Alexa Top 500 web sites. None of them were framebusting 
> correctly with JavaScript.
> 
> http://w2spconf.com/2010/papers/p27.pdf

On Fri, 21 May 2010, Perry Smith wrote:
>
> This probably is not the right list for this but seems like the 
> X-FRAME-OPTIONS http header could be strengthened by having the UA send 
> all requests from pages that have the X-FRAME-OPTIONS to also containt 
> either the X-FRAME-OPTIONS or another tag.  One weakness pointed out in 
> the paper is that proxies can strip the header.  If the server doesn't 
> see the header come back, it would know that it got stripped out and the 
> request needs to be questioned.  I don't know if there is a way to 
> introduced "fake" http headers into requests or not.  If there is, that 
> would need to be addressed too.

Given all the above, I haven't changed the spec. Scripts still run in 
designMode, and don't run in sandboxed iframes. We should specify 
X-Frame-Options and CSP (ideally in the same spec so that they work 
together well); when that is being done I'd be happy to define how the 
sandboxing features interact with them.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'