valentinium at gmail.com (2018-06-20T01:57:27.734Z)
Aha! Thanks. I think I get what you mean now.
Let’s say I have this CSP:
```
content-security-policy: script-src 'nonce-foo'
```
And I have this in my document:
```
<script nonce=foo type=module>
import 'data:text/javascript,console.log(`bar`)';
</script>
```
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.
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:
```
<!DOCTYPE html>
<meta http-equiv=content-security-policy content="script-src 'nonce-foo'">
<script nonce=foo type=module>
import 'data:text/javascript,document.open();document.writeln(`<p>static import of data URI module worked</p>`)';
document.writeln(`<p>nonce module worked</p>`);
import('data:text/javascript,document.writeln(`<p>dynamic import of data URI module worked</p>`)');
</script>
```
demo: https://necessary-hallway.glitch.me/
All three seem to work! Very cool.
Sorry for the diversion from the main topic. This was really interesting
and I appreciate the explanation.valentinium at gmail.com (2018-06-20T01:52:20.843Z)
Aha! Thanks. I think I get what you mean now.
Let’s say I have this CSP:
```
content-security-policy: script-src 'nonce-foo'
```
And I have this in my document:
```
<script nonce=foo type=module>
import 'data:text/javascript,console.log(`bar`)';
</script>
```
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.
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:
```
<!DOCTYPE html>
<meta http-equiv=content-security-policy content="script-src 'nonce-foo'">
<script nonce=foo type=module>
import 'data:text/javascript,document.open();document.writeln(`<p>static import of data URI module worked</p>`)';
document.writeln(`<p>nonce module worked</p>`);
import('data:text/javascript,document.writeln(`<p>dynamic import of data
URI module worked</p>`)');
</script>
```
demo: https://necessary-hallway.glitch.me/
All three seem to work! Very cool.
Sorry for the diversion from the main topic. This was really interesting
and I appreciate the explanation.
Aha! Thanks. I think I get what you mean now. Let’s say I have this CSP: ``` content-security-policy: script-src 'nonce-foo' ``` And I have this in my document: ``` <script nonce=foo type=module> import 'data:text/javascript,console.log(`bar`)'; </script> ``` 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. 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: ``` <!DOCTYPE html> <meta http-equiv=content-security-policy content="script-src 'nonce-foo'"> <script nonce=foo type=module> import 'data:text/javascript,document.open();document.writeln(`<p>static import of data URI module worked</p>`)'; document.writeln(`<p>nonce module worked</p>`); import('data:text/javascript,document.writeln(`<p>dynamic import of data URI module worked</p>`)'); </script> ``` demo: https://necessary-hallway.glitch.me/ All three seem to work! Very cool. Sorry for the diversion from the main topic. This was really interesting and I appreciate the explanation. On Tue, Jun 19, 2018 at 8:58 PM Mike Samuel <mikesamuel at gmail.com> wrote: > Sorry for the confusion. > > Nonces are just for elements with url attributes. > > 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. > > 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. > > But there is a risk with the import operator since it's input is not part > of an already trusted input. > > On Tue, Jun 19, 2018, 8:22 PM Darien Valentine <valentinium at gmail.com> > wrote: > >> 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. >> >> On Tue, Jun 19, 2018 at 8:06 PM Mike Samuel <mikesamuel at gmail.com> wrote: >> >>> 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. >>> >>> On Tue, Jun 19, 2018, 7:57 PM Darien Valentine <valentinium at gmail.com> >>> wrote: >>> >>>> 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. >>>> >>>> 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.) >>>> >>>> On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi < >>>> andrea.giammarchi at gmail.com> wrote: >>>> >>>>> sorry, I meant: >>>>> >>>>> JSON.stringify('data:text/javascript,' + >>>>> moduleContentAfterTreeShaking); >>>>> >>>>> >>>>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi < >>>>> andrea.giammarchi at gmail.com> wrote: >>>>> >>>>>> >>>>>> 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. >>>>>>> >>>>>>>> >>>>>> I meant even synchronously, with a pre-processor that replace the >>>>>> imported module with >>>>>> >>>>>> 'data:text/javascript,' + >>>>>> JSON.stringify(moduleContentAfterTreeShaking); >>>>>> >>>>> >>>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180619/f45b4379/attachment.html>