Re: wasm-unsafe-eval script-src directive

Hi Dan,

Just so there's no confusion, I haven't worked on this proposal, it's just
something I'm interested in helping push forward. While URI origin would be
great, it seems to involve quite a bit more work on all browsers than
adding the 'wasm-unsafe-eval' directive, which would be a huge step forward
in terms of reducing potential exploits.

-Charles V

On Tue, Dec 10, 2019 at 12:23 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> On Tue, Dec 10, 2019 at 11:19 AM Charles Vaughn <cvaughn@gmail.com> wrote:
>
>> I'm a dev at Tableau, and Mike West pointed me here after a PR I made to
>> enable this for Chrome. For background, this is the proposal here:
>> https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md#proposed-wasm-unsafe-eval-directive
>>
>>
>
> Thanks for the work that went into this plan.
>
> wasm-unsafe-eval, or maybe even just 'wasm-eval' seems reasonable.
>
> The hash bit needs work -- on our side more than in your proposal. We
> don't want to calculate the hash over streaming resources, and currently
> don't support SRI for fetch. For content that isn't in-line CSP requires
> the script tag to contain an "integrity" attribute, and then we simply
> match the CSP hash against integrity attributes. Enforcement is left up to
> SRI itself. fetch() is an obvious gap and we've batted around ideas like
> adding an optional object param that could have an integrity property to
> match against, but so far nothing concrete. Extending hash to WASM is
> probably a good idea but it would have to build on something like that.
>
> For source whitelisting the fetch itself would need to have the same
> sources whitelisted in connect-src. Do we need to double down and list them
> as a wasm source as well?
>
> Good food for thought, thanks!
>
> -Dan Veditz
>