- From: Mike West <mkwst@google.com>
- Date: Mon, 10 Dec 2012 21:52:11 +0100
- To: "Eduardo' Vela" <evn@google.com>
- Cc: "public-web-security@w3.org" <public-web-security@w3.org>, Adam Barth <w3c@adambarth.com>
- Message-ID: <CAKXHy=f6tpJzpFd_0ToCPqrqsKAtkzGawjhT09qzuJES7P3HSg@mail.gmail.com>
The goal of the `script-nonce` directive is to handle at least some of this use-case: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-nonce--experimental Rather than altering the behavior of `innerHTML`, it asks developers to tag inline script blocks that are intentionally included with a unique key, generated on the fly for each request. Bad for caching, not particularly useful for static sites, but useful for the (many?) applications that can't kill inline scripts. Would that suit your requirements? -- Mike West <mkwst@google.com>, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 On Sun, Dec 9, 2012 at 2:57 AM, Eduardo' Vela <evn@google.com> wrote: > Hi! > > For some pages (think, static content, or heavy JS sites), the only risk > of XSS is DOM XSS, and one can't realistically convert all inline scripts > to outline for performance reasons. > > ATM the only way to protect these pages is by creating the CSP header when > the document finished loading (after onload or so), however that won't > catch the scripts that are created before load time, like > <script>xx.innerHTML=xxx</script> > > I want to propose something, maybe for CSP 1.1, 1.2, 1.x 2.x or whatever, > that allows us to disable the behavior that makes innerHTML introduce XSS > (and so, make innerHTML safe by default). > > Of course the same has to be done to insertAdjacentHTML, outerHTML, etc.. > but the idea still holds. > > It's unclear to me how to define an API for this, but here's a stab: > * script-src unsafe-static-inline > * document.write/innerHTML/etc.. won't execute scripts. > > In the future one could expand the syntax to only allow "safe" strings or > "untainted" strings.. but I don't want to go into details about that. > > The objective of this thread is to ignite discussion and flaming, I don't > realistically expect everyone to agree on something any time soon. >
Received on Monday, 10 December 2012 20:53:01 UTC