LottieFiles / dotlottie-web

Official LottieFiles player for rendering Lottie and dotLottie animations in the web. Supports React, Vue, Svelte, SolidJS and Web Components.
https://developers.lottiefiles.com/docs/dotlottie-player/
MIT License
191 stars 11 forks source link

Unsafe-eval CSP issue #337

Open kevinvugts opened 3 months ago

kevinvugts commented 3 months ago

Overview

Dear,

I am concerned about the @lottiefiles/dotlottie-react library since it makes use of unsafe-eval. I have to enabled it to make the Lottie file work but I am doubting if this is the way to go.

Could you guys elaborate more on this security topic?

theashraf commented 3 months ago

@kevinvugts I couldn’t find any usage of eval within the dotlottie-* packages. Could you provide more details to help me investigate further?

I’ll also implement an ESLint rule to check for unsafe-eval in the CSP, which should help me identify the root cause.

theashraf commented 3 months ago

Based on this issue -> https://github.com/emscripten-core/emscripten/issues/20994, passing -sDYNAMIC_EXECUTION=0 when building the WASM bindings in the dotlottie-rs core player should fix this issue.

Update: This approach does not resolve the problem, as DYNAMIC_EXECUTION is already disabled in the core player (see https://github.com/LottieFiles/dotlottie-rs/blob/main/Makefile#L263) 🤔

theashraf commented 3 months ago

@kevinvugts One potential solution to consider is using wasm-unsafe-eval in your CSP header.

The wasm-unsafe-eval directive specifically controls WebAssembly execution and is more specific than unsafe-eval. If wasm-unsafe-eval is not specified in the script-src directive, WebAssembly will be blocked from loading and executing on the page. For more details, you can refer to this documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_webassembly_execution

kevinvugts commented 3 months ago

@kevinvugts One potential solution to consider is using wasm-unsafe-eval in your CSP header.

The wasm-unsafe-eval directive specifically controls WebAssembly execution and is more specific than unsafe-eval. If wasm-unsafe-eval is not specified in the script-src directive, WebAssembly will be blocked from loading and executing on the page. For more details, you can refer to this documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_webassembly_execution

Thank you so much for getting back to me. However, may I ask why the there are references to eval? This is a potential security hazard and shouldn't be present in a core library of LottieFiles in my opinion. CSP policies nowadays prevent these type of attacks by disabling them.

And I don't feel comfortable enabling these inline scripts to be able to be executed. What is your view on this?

theashraf commented 3 months ago

@kevinvugts, This issue arises from the generated code by the Emscripten library, which compiles our core dotLottie Rust player and handles the WebAssembly and JS-binding "glue" code.

It’s a common issue, as discussed here: https://github.com/WebAssembly/content-security-policy/issues/7. You might find success using wasm-unsafe-eval.

kevinvugts commented 2 months ago

wasm-unsafe-eval

Hi @theashraf

I think this would work for now. However, as the name suggests "wasm-unsafe-eval" it probably isn't a really secure option.

Isn't there another way to compile your core library? As this might open a lot of security risks to all users that use this native library of Lottie. :(

github-actions[bot] commented 3 weeks ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.