Unfortunately, you can't implement CSP that way. Consider the case of two same-origin iframes A and B. Suppose A has a restrictive CSP policy (say that bans everything) and B doesn't. If B uses the DOM to insert a script element into A, then CSP should block that script element from executing. Stripping script tags at parse time won't.
Adam On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen <gga...@apple.com> wrote: > Hi folks. > > Currently, we have two different ways to disable JavaScript execution: > > (1) Paste / Drag n Drop / editing: Remove script elements and script > attributes from untrusted source markup at parse time. > > (2) JavaScript disabled setting / Content Security Policy: Check settings > and/or CSP at runtime. > > There are problems with mode (2): > > * It breaks features that are implemented in JavaScript. > > The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari > autofill all run JavaScript. This means that they break when users disable > JavaScript. > > As a defense against phishing attacks, mail clients and other web content > readers disable JavaScript. This means that they can't implement pieces of > their UI in JavaScript. > > (FWIW, WebKit violates the CSP specification in this regard: "Enforcing a CSP > policy should not interfere with the operation of user-supplied scripts such > as third-party user-agent add-ons and JavaScript bookmarklets.") > > * It subjects users to XSS attacks. > > Runtime checking mode leaves inert JavaScript in the untrusted document. This > is a risky proposition. Operations that clone or adopt nodes from the > untrusted document unwittingly re-vivify that inert JavaScript, subjecting > the user to attack. Experience shows that this is a difficult programming > model to get right. > > * It's hard to verify. > > We have 18 different call sites to canExecuteScripts() in WebKit, not > counting the call sites that pertain to plug-ins. Are you confident we've > caught all the right places? Do you know if the feature you just added needs > to call canExecuteScripts()? > > * It's two different ways to do the same thing. > > Simplicity is a goal of the WebKit project. > > > Proposal: > > If -- for any reason -- JavaScript is disabled in a given document, the > document parser will elide all JavaScript. This means that runtime checks can > be removed. > > One potential downside to this proposal is that it changes the document's > internal structure. Since the changes are not generally observable, since > they only take place when we're already making much bigger changes by > preventing whole scripts from running, and since we haven't seen any > compatibility problems from our paste / drag n drop / editing behavior in > this regard, I think this downside is acceptable. > > Another potential downside is that CSP errors will be reported at parse time > instead of runtime. FWIW, some authors might see this as an upside. > > Any objections? > > Thanks, > Geoff > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
