Inline ES Modules
valentinium at gmail.com
Wed Jun 20 00:22:26 UTC 2018
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>
>> 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
>> 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
>> 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:
>>> 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
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss