- From: Jim Manico <jim.manico@owasp.org>
- Date: Thu, 2 Apr 2015 10:05:21 -0700
- To: Crispin Cowan <crispin@microsoft.com>
- Cc: Mike West <mkwst@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Justin Fagnani <justinfagnani@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <1010196954155607768@unknownmsgid>
There are edge cases where inline script is necessary, like when dynamically loading JS based on certain conditions. Those edge cases are rare and only needed for extreme performance tuning. -- Jim Manico @Manicode (808) 652-3805 On Apr 2, 2015, at 9:37 AM, Crispin Cowan <crispin@microsoft.com> wrote: Mixing code inline with data is **always** a bad idea. The web never should have allowed inline script, but it is too late to fix that now. The best we can do is avoid creating **new** opportunities to mix code with data. So, I would block inline event handlers just on principle, unless there is some compelling compat need. *From:* Mike West [mailto:mkwst@google.com <mkwst@google.com>] *Sent:* Wednesday, April 1, 2015 11:50 PM *To:* Devdatta Akhawe *Cc:* Justin Fagnani; public-webappsec@w3.org *Subject:* Re: HTML Imports and CSP On Thu, Apr 2, 2015 at 6:32 AM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > Sure, why not? I'm not a huge fan of inline event handlers, but I don't > think that allowing them (and inline script) in Imports actually increases > the risk a developer exposes herself to. Do you think that's an incorrect > analysis? There is a huge difference in risk of XSS in inline event handlers and inline scripts. Different types of contexts, nested contexts etc all are issues. *cough* I think Joel wrote a paper about this :D You're not wrong there; inline event handlers are bad and they should feel bad. That said, is the risk really different in kind from just allowing plain old inline script that executes directly? It doesn't seem to be. Allowing one without allowing the other seems capricious. > There's a difference between supporting a new feature which isn't currently > covered by any directive, and changing the meaning of a directive that > already covers a featue. Again, because of the DOMXSS risk (even just injecting a new inline script tag without nonce), I think not using a new directive messes up the security invariants for any CSP adopters. If we move imports from `script-src` to `import-src`, then sites that currently disallow imports will no longer have that protection. That seems bad. What's your ideal solution? -mike
Received on Thursday, 2 April 2015 17:05:52 UTC