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
