8 ms·
That and you need to allow unsafe scripts in your CSP to support WASM in Chrome, so it's a bit of a killer for anything that takes security seriously.
by hackcasual 7y ago
That and you need to allow unsafe scripts in your CSP to support WASM in Chrome, so it's a bit of a killer for anything that takes security seriously.
- simcop2387 7y agoGood chance that'll start to change as WASM gets more fleshed out and more commonly used, but that is a barrier to it's adoption at the moment.
- dmix 7y agoWhat's stopping it exactly?
- dmix 7y agoNevermind found time to research it myself, this was a good overview https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md https://github.com/WebAssembly/content-security-policy/blob/...
- namibj 7y agoChrome restricts it to unsafe-eval CSP. The main risk described seems to be escaping to the global object. Can't we use the power of a tracing GC to determine whether the global object is reachable from the import object, and put _that_ under unsafe-eval? Or add descriptions/tags that need to explicitly allow dangerous APIs to be reachable by the import object, and refuse if any undeclared dangerous APIs are reachable with a CSP not containing unsafe-eval? I see both sides, but full unsafe-eval is too much of a wrecking ball when a warded lock[0] on this proverbial door to the WASM kingdom would be sufficient. [0]: https://en.wikipedia.org/wiki/Warded_lock https://en.wikipedia.org/wiki/Warded_lock
- hackcasual 7y agoBoth FireFox and Safari support same origin CSP on instantiateStreaming sources though, which doesn't work on Chrome.
- namibj 7y agoI actually mean even harsher restrictions than just some same-origin. Specifically, I mean using already-existing mechanics to figure out whether the global object is reachable by the WASM code. If so, treat as unsafe-eval for all I care. If not, treat as risky as the functionality exposed to the WASM code (testing reachability for other objects/functions that are not the global object itself).