<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018 at 9:50 PM Darien Valentine <<a href="mailto:valentinium@gmail.com">valentinium@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Aha! Thanks. I think I get what you mean now.</div><div><br></div><div>Let’s say I have this CSP:</div><div><br></div><div>```</div><div>content-security-policy: script-src 'nonce-foo'</div><div>```</div><div><br></div><div>And I have this in my document:</div><div><br></div><div>```</div><div><script nonce=foo type=module></div><div>  import 'data:text/javascript,console.log(`bar`)';</div><div></script></div><div>```</div><div><br></div><div>Then the browser could theoretically ignore the absence of 'data:' in the CSP safely because the import statement here is part of a nonce-allowed script. And the unsafety is adding `data:` to the CSP (which would then be available for third party scripts I might also allow), not using `data:` in my own trusted modules; and there is a minor bit of unsafety associated with dynamic import, but it’s not in the same league as the unsafety potentially implied by a blanket permission for all `data:` URI sources.</div><div><br></div><div>I was surprised that this nuance was considered. I figured it just blindly asked "is this source permitted by the CSP" without taking into account whether the trust from a parent resource could be implicitly extended. But I see you’re totally right:</div><div><br></div><div>```</div><div><!DOCTYPE html></div><div><meta http-equiv=content-security-policy content="script-src 'nonce-foo'"></div><div><script nonce=foo type=module></div><div>  import 'data:text/javascript,document.open();document.writeln(`<p>static import of data URI module worked</p>`)';</div><div>  document.writeln(`<p>nonce module worked</p>`);</div><div>  import('data:text/javascript,document.writeln(`<p>dynamic import of data URI module worked</p>`)');</div><div></script></div><div>```</div><div><br></div><div>demo: <a href="https://necessary-hallway.glitch.me/" target="_blank">https://necessary-hallway.glitch.me/</a></div><div><br></div><div>All three seem to work! Very cool.</div></div></blockquote><div><br><a href="https://github.com/w3c/webappsec-csp/issues/243">https://github.com/w3c/webappsec-csp/issues/243</a> : "Any protection against dynamic module import?"</div><div>captures the discussion on this.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Sorry for the diversion from the main topic. This was really interesting and I appreciate the explanation.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018 at 8:58 PM Mike Samuel <<a href="mailto:mikesamuel@gmail.com" target="_blank">mikesamuel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Sorry for the confusion.</div><div dir="auto"><br></div><div dir="auto">Nonces are just for elements with url attributes.</div><div dir="auto"><br></div><div dir="auto">I mentioned nonces to point out that strict CSP policies can allow some data: urls without having to explicitly whitelist or hash the entire content.</div><div dir="auto"><br></div><div dir="auto">Separately I wanted to say that there is no incompatibility between the goals of CSP and import statements that use a data: module specifier, since we already trust the compilation unit and there's no actual network message leaked.</div><div dir="auto"><br></div><div dir="auto">But there is a risk with the import operator since it's input is not part of an already trusted input.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Tue, Jun 19, 2018, 8:22 PM Darien Valentine <<a href="mailto:valentinium@gmail.com" target="_blank">valentinium@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Mike: Ah, cool, I didn’t realize that — I had thought that nonces were just for whitelisting inline script elements. How does one specify a nonce in association with a data URI? I’m having trouble turning up a description / example of how it would work. Or possibly I’m misunderstanding this quite a bit, hm ... I’m also confused by the relationship between import/import() and XSS that you’ve described.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel <<a href="mailto:mikesamuel@gmail.com" rel="noreferrer" target="_blank">mikesamuel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">CSP with data URIs is possible via nonce sources.  For data: module descriptors browsers could safely skip the CSP check since it doesn't allow XSS unless one can already specify an import statement which typically means one can specify arbitrary JS.  That argument doesn't extend to the import operator though so you'd have to tolerate assymetry there.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018, 7:57 PM Darien Valentine <<a href="mailto:valentinium@gmail.com" rel="noreferrer" target="_blank">valentinium@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Andrea: That is a really interesting approach. I would point out that using data URIs for js means the `data:` scheme has to be a permitted source for script-src. This allowance has roughly the same security implications as permitting `unsafe-eval`. I know most people aren’t using CSPs yet, but personally I’d be wary of a solution that makes it harder to adopt a strong CSP.<div><br></div><div>A super dorky/tangential aside that probably doesn’t matter at all but ... I notice you used application/javascript for the media type. There’s a contradiction between the IANA media type registry and the HTML 5 spec with regard to the "correct" media type to use for JS. RFC 4329 says application/javascript is the only value that should be used, while HTML says text/javascript is the only value that should be used. I believe (not sure though) that this is because it’s the most backwards-compatible value. Given that the media types registry seems to be basically dead to web standards (if we follow the registry we can’t serve or post a bunch of media types acknowledged or defined by web standards at all, including image/webp, application/csp-report, etc) and the code has to run in a browser, I’d tend to think HTML is the better spec to follow ... though I guess when two specs contradict each other it’s hard to make an objective case for one being more authoritative. (I’d be curious if there’s a specific reason you know of to prefer to RFC definition though. When standards don’t align it breaks my tiny heart.)</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" rel="noreferrer noreferrer" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">sorry, I meant:<div><br></div><div><span style="font-size:12.8px">JSON.stringify(</span><span style="font-size:12.8px">'data:text/javascript,' +</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">moduleContentAfterTreeShaking)</span><span style="font-size:12.8px">;</span></div><div><div class="gmail-m_-6186798431334070077m_-5935691179425642150m_5757763646263996298m_5996744960790005742m_-7042077783952433031m_-7893142097671734128gmail-yj6qo" style="font-size:12.8px"></div></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" rel="noreferrer noreferrer" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I think these are all nice to have features, but I also think we have all the primitives we need to make it happen via pre-processing.</div></div><div class="gmail-m_-6186798431334070077m_-5935691179425642150m_5757763646263996298m_5996744960790005742m_-7042077783952433031m_-7893142097671734128m_8964347681135286029gmail-HOEnZb"><div class="gmail-m_-6186798431334070077m_-5935691179425642150m_5757763646263996298m_5996744960790005742m_-7042077783952433031m_-7893142097671734128m_8964347681135286029gmail-h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-6186798431334070077m_-5935691179425642150m_5757763646263996298m_5996744960790005742m_-7042077783952433031m_-7893142097671734128m_8964347681135286029gmail-m_-6293974704123965851HOEnZb"><div class="gmail-m_-6186798431334070077m_-5935691179425642150m_5757763646263996298m_5996744960790005742m_-7042077783952433031m_-7893142097671734128m_8964347681135286029gmail-m_-6293974704123965851h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span><div></div></span></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div></span><div>I meant even synchronously, with a pre-processor that replace the imported module with</div><div><br></div><div>'data:text/javascript,' + JSON.stringify(moduleContentAfterTreeShaking);<br></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" rel="noreferrer noreferrer" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" rel="noreferrer" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div></div></div>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div></div>