New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: call to eval() blocked by CSP #274

Closed
athoune opened this Issue Sep 15, 2016 · 10 comments

Comments

Projects
None yet
5 participants
@athoune

athoune commented Sep 15, 2016

It happens when the website use strict HSTS headers.

@posativ

This comment has been minimized.

Owner

posativ commented Sep 15, 2016

Yup, found the same behavior last week when I applied random security headers.

@athoune

This comment has been minimized.

athoune commented Sep 15, 2016

I don't understand the eval trick, "js" is already a function. Why do you a back flip followed by a front flip?

@posativ

This comment has been minimized.

Owner

posativ commented Sep 16, 2016

JavaScript development sucks?

@athoune

This comment has been minimized.

athoune commented Sep 16, 2016

Sure, but Isso is a great product, the perfect sidekick for static website.

Here is the context for my question :

var fn;
eval("fn = " + js);
return fn;

@posativ posativ added the client label Sep 16, 2016

@mdosch

This comment has been minimized.

mdosch commented Oct 20, 2016

May this be useful? https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/eval

I tried a little bit to replace the eval, but wasn't succesful so far. No wonder, as I'm no programmer and so it's just trial and error.

@posativ

This comment has been minimized.

Owner

posativ commented Oct 21, 2016

It will not work without, due to the embedded template with executable code. A different approach for templates is needed.

@Libbum

This comment has been minimized.

Libbum commented Apr 15, 2017

Just to add this discussion: the specific header that's causing the problem here is the Content Security Policy (CSP), not HSTS. Users must add unsafe-eval to the script-src portion of their CSP policy. This is considered quite a harmful action, which drops your security score by 15 points on the Mozilla Observatory tests.

I've only just moved across to isso from Disqus, so don't have an answer to this issue just yet, but I'll certainly look into it - I think this task should be set to quite a high priority.

@mdosch

This comment has been minimized.

mdosch commented Sep 9, 2017

Is anyone having an idea about a possible solution? As the isso js is the only script on my website it isn't really unsafe to have "unsafe-eval" in CSP but also it doesn't really look good and it is a principle of mine to try to configure my website as safe as possible.

@Libbum the Observatory actually dropped my rating now from A to B+ by -20 points due to unsafe CSP implementation. I think this very confusing as they should consider I load only one script from my own host and not potential malicous stuff from Google, Facebook or other Tracking-companies.

@Libbum

This comment has been minimized.

Libbum commented Sep 9, 2017

@mdosch, as posativ has stated, the issue is with the way templating is handled. Isso is using an old version of Pug (which used to be called Jade) and is quite embedded into the code. I attempted to upgrade to the latest Pug version to attempt a fix, but never managed to get there. I'm not even sure that will fix the problem anyway. Templating is a tough job and removing it entirely would just make the code uglier and more difficult regardless. So for the moment I'm at a loss on how to proceed.

I agree with your sentiment and principles though and it really irks me to have this policy running. So I'm actively working on something new as a personal project to learn Elm and work with Rocket. No where near done and I'm not sure if it ever will be, but keep an eye on it as a possible future solution.

@vincentbernat

This comment has been minimized.

Contributor

vincentbernat commented Apr 17, 2018

I am not familiar with this templating system. Wouldn't it be possible to precompile the functions and skip the eval step? The eval step could stay during development but would go away in the minimal version.

vincentbernat added a commit to vincentbernat/isso that referenced this issue Apr 17, 2018

jade: avoid using eval once compiled
Use of eval is handy when we need to automatically reload a
template. However, in production, this is slow and unsafe. Moreover,
when using CSP, we have to use 'unsafe-eval' which brings shame to
most of us. It appears use of eval() is not needed because the
template has already been translated to Javascript. We just need to
bind "jade" to its local scope.

So, we add an additional wrapper function binding "jade" to the local
scope. Moreover, when compiling the template, we add a flag to the
function to know it has already been compiled. In this case, we
execute it with "jade" in its scope. Otherwise, we keep using eval.

Quickly tested in both situations. Seem to work.

Fix posativ#274.

vincentbernat added a commit to vincentbernat/isso that referenced this issue Apr 22, 2018

jade: avoid using eval once compiled
Use of eval is handy when we need to automatically reload a
template. However, in production, this is slow and unsafe. Moreover,
when using CSP, we have to use 'unsafe-eval' which brings shame to
most of us. It appears use of eval() is not needed because the
template has already been translated to Javascript. We just need to
bind "jade" to its local scope.

So, we add an additional wrapper function binding "jade" to the local
scope. Moreover, when compiling the template, we add a flag to the
function to know it has already been compiled. In this case, we
execute it with "jade" in its scope. Otherwise, we keep using eval.

Quickly tested in both situations. Seem to work.

Fix posativ#274.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment