- From: Brian Smith <brian@briansmith.org>
- Date: Mon, 9 Feb 2015 00:06:11 -0800
- To: Mike West <mkwst@google.com>
- Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Mike West <mkwst@google.com> wrote: > https://github.com/w3c/webappsec/commit/457db7f0596304073410f0791dfdf6329b33970f > addresses the specific concern +1'd here. WDYT? I think it is good to have such text discouraging the use of nonce. But, I think it is important to explain the security issues that nonce has so that the reader can understand *why* nonce is not secure. Feel free to use any of the text in my previous emails describing those issues. > Consider a page that includes a third-party widget. Or an ad. It's quite > likely that the page doesn't actually know what's going to be loaded via > that widget, so constructing a CSP which would allow those things is > difficult. Nonces, being easily transferrable, allow such embedded content > to bring in whatever it requires. I think that use case is one for which we should find alternative solutions. In particular, we should be moving the web towards social widgets and ads being confined within iframe sandbox so that embedding an ad or widget doesn't give the ad/widget provider full control over the page's origin like <script src=//third-party.example.com/ad.js> does. So, I think that allowing CSP nonce to have DOM XSS vulnerabilities in order to support the use case above is doubly counterproductive. > https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0020.html is > an example of that kind of use case, which isn't at all uncommon. In that thread, I agree with what Florian Weber said and the message by Sean Snider at [1]. Cheers, Brian [1] https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0099.html
Received on Monday, 9 February 2015 08:06:41 UTC