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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> wrote: >>> >>>> sorry, I meant: >>>> >>>> JSON.stringify('data:text/javascript,' + moduleContentAfterTreeShaking) >>>> ; >>>> >>>> >>>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi < >>>> [email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
