- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 14 Jun 2011 10:10:31 -0700
- To: Brandon Sterne <bsterne@mozilla.com>
- Cc: Brian Smith <bsmith@mozilla.com>, public-web-security@w3.org
On Tue, Jun 14, 2011 at 9:49 AM, Brandon Sterne <bsterne@mozilla.com> wrote: > On 06/10/2011 04:57 PM, Brian Smith wrote: >> Brandon Sterne wrote: >>> I just pushed a changeset that adds XSLT stylesheets to the style-src >>> directive: >>> https://dvcs.w3.org/hg/content-security-policy/rev/6f4cab889cb5 >> >> How would CSP affect the document() function in XSLT, which can import nodes from external documents? >> >> CSS can change how a page is displayed, but XSLT actually changes the content of the page. XSLT is a turing-complete, though tedious, programming functional programming language. IIRC, there are various XSLT extensions that are potentially dangerous, but I don't know if any browsers implement them. XSLT seems much more like JavaScript than it is like CSS. >> >> If I were a content author, I would very much like to block all XSLT, completely, without having to block JS or CSS. >> >> Cheers, >> Brian > > I spoke with Brian a bit more yesterday, and he convinced me that > bucketing XSLT with style-src is a bad idea. Before we spoke, my > feeling was that the increased capabilities of XSLT over CSS stylesheets > were mitigated both by the fact they can only be used in XML documents, > and that any content added by the XSLT would be subject to the > document's CSP. The first mitigation will be of small comfort to XHTML > pages or HTML pages that are well-formatted XML. The second mitigation > doesn't fully account for changes to the DOM that XSL transforms are > capable of and which might be unexpected by the transformed page. The > XSL stylesheet can add and remove nodes that might affect the security > properties of a page. XSLT could remove the script node, for instance, > that was responsible for frame busting. > > So I think we either need to create a different category (xslt-src?) for > XSL stylesheets, or lump them with script-src which sites will > understand has a higher risk profile. Thoughts? I'd lump them in with script-src. The problem is that they're somewhat obscure and authors aren't going to understand the security implications. If you and I didn't get it right the first time, what chance do author's have? Adam
Received on Tuesday, 14 June 2011 17:11:30 UTC