[whatwg] Should scripts and plugins in contenteditable content be enabled or disabled?
Ian Hickson
ian at hixie.ch
Thu Jul 29 17:29:58 PDT 2010
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list