问题
We use the following CSP header:
default-src 'self' *.ourdomain.com; script-src 'self' *.ourdomain.com 'sha256-[...]' 'unsafe-eval';
connect-src 'self' *.ourdomain.com;
style-src 'unsafe-inline' * 'self' data:; font-src *;
img-src * 'self' data:
The recommendation by our security team is not use unsafe-eval.
My question is: as long as we are using sha256-[...] to restrict any script that we haven't deployed ourselves, what is the security risk of still keeping unsafe-eval in the CSP header? In what situation would this still expose us to cross-site attacks?
回答1:
Because eval is literally unsafe. Eval in every language means "take this string and execute it code." Sure, you may be using eval in a semi-safe way, but as long as you allow it at all, you are saying "anyone is allowed to execute arbitrary code in my application given an entry point".
It is my opinion that there is no reason to use eval. Show me a case where eval is required in actual useful code and I'll bet that I can rewrite the code without using eval or declare it as impossibly secure code.
Disallowing Inline script is only half the battle, especially if you use jquery.
Quiz: does this code trigger an inline script violation or an eval violation?
$('body').html('<script>alert(1)</script>')
You may be surprised.
Spoiler:
it's eval
回答2:
The security risk is that it doesn't protect any of your own code that may be vulnerable because eval is used.
If you are using eval in your own code you should question why. Is there a safer alternative that can be employed instead?
See here for a (contrived) example of how code can be injected by an attacker. Of course whether this can be done to your site very much depends on your code.
The upshot is that there's almost always an alternative to using eval.
来源：https://stackoverflow.com/questions/37155270/content-security-policy-csp-safe-usage-of-unsafe-eval