Removing the need for javascript "Eval" function - is it possible and desirable?
Hi all,
At the moment we have implemented a Content Security Header policy for our Umbraco websites that is as strict as possible.
Unfortunately we have to add the “unsafe-inline” CSP header for each Umbraco website, because in the Umbraco backoffice javascript code the “eval” function is still used on several locations in the code base.
Our security officers are –of course- not happy with this situation.
And we developers have to explain, after each security test, the reason for this “unsafe-inline” CSP header.
I had a short email conversation with Shannon about this. Following his suggestion I just looked at the current Umbraco 8 source code. And unfortunately there are still several javascript files that use the eval function:
So, what is your opinion about this as Umbraco developers?
Should we/Umbraco strive to ban the "eval" function from its code base?
And will this be possible?
But I first wanted to get a feeling about the urgency and feasability.
Am I -as a developer- and our security officers of our company the only ones who thinks this is an issue?
And because I do not know the Umbraco javascript source code where it is used, I don't know if it is even possible to get rid of eval...
Umbraco are always looking to improve security where possible.
Having it on the issue tracker will raise awareness and may result in someone picking it up in the community or at the very least get it in front of the right people :)
the security approach we're taking is to have a different Content Security Policy header for the /umbraco/-folder and for the public website.
The public website is more stricter (and only contains our own code). The /umbraco/-folder has it's own web.config where we have a bit looser CSP header.
We do the same for example for upload limits in the web.config (we do not people in the frontend sending us images of 10 Mb, but we do allow our Umbraco editors to do so). Furthermore we restrict access to /Umbraco/ based on IP-addresses.
Maybe this is a good workaround for you!
===
And it should be better if Umbraco fixed these, but I think they (should) have other priorities :)
We have taken the same approach as Jeffrey suggests. Hardened by default in root config and add exceptions to make the backoffice and controllers etc work.
Removing the need for javascript "Eval" function - is it possible and desirable?
Hi all,
At the moment we have implemented a Content Security Header policy for our Umbraco websites that is as strict as possible. Unfortunately we have to add the “unsafe-inline” CSP header for each Umbraco website, because in the Umbraco backoffice javascript code the “eval” function is still used on several locations in the code base.
Our security officers are –of course- not happy with this situation. And we developers have to explain, after each security test, the reason for this “unsafe-inline” CSP header.
I had a short email conversation with Shannon about this. Following his suggestion I just looked at the current Umbraco 8 source code. And unfortunately there are still several javascript files that use the eval function:
According to the Mozilla javascript reference:
"Do not ever use eval!"
So, what is your opinion about this as Umbraco developers? Should we/Umbraco strive to ban the "eval" function from its code base? And will this be possible?
Hi
I may be worth raising it as a Securtiy issue on github repo - https://github.com/umbraco/Umbraco-CMS/issues/new/choose
Matt
Hi Matthew,
Yes, I might do that.
But I first wanted to get a feeling about the urgency and feasability.
Am I -as a developer- and our security officers of our company the only ones who thinks this is an issue? And because I do not know the Umbraco javascript source code where it is used, I don't know if it is even possible to get rid of eval...
Umbraco are always looking to improve security where possible.
Having it on the issue tracker will raise awareness and may result in someone picking it up in the community or at the very least get it in front of the right people :)
Matt
Hi Wouter,
the security approach we're taking is to have a different Content Security Policy header for the /umbraco/-folder and for the public website.
The public website is more stricter (and only contains our own code). The /umbraco/-folder has it's own web.config where we have a bit looser CSP header.
We do the same for example for upload limits in the web.config (we do not people in the frontend sending us images of 10 Mb, but we do allow our Umbraco editors to do so). Furthermore we restrict access to /Umbraco/ based on IP-addresses.
Maybe this is a good workaround for you!
===
And it should be better if Umbraco fixed these, but I think they (should) have other priorities :)
Regards, Jeffrey
Hi Jeffrey,
Thanks, sounds like a good workaround until this is fixed in Umbraco. I wonder why I have never thought about doing it like this... :-|
We already have the white listed IP addresses for backoffice access though :-)
We have taken the same approach as Jeffrey suggests. Hardened by default in root config and add exceptions to make the backoffice and controllers etc work.
Frederik
is working on a reply...