A change is comin... Not just yet but tentatively for 11.0 (around April 2021), we plan to add a new admin module to manage and enforce CSP. We want to ensure that you are ready for the change and understand what a CSP is.
A Content Security Policy - typically written as CSP - is a set of directives for a web site that tells browsers what content can and cannot be served on the site - not just the visuals, but scripts too. But, if I am the one putting content on my site, do I really need a separate policy for the browser? Yes, yes you do. Sure if you are the absolute only person adding content to your site, you can be confident in your choices of content to allow. That's great. What you cannot control is outside entities hacking to access and/or manipulate your site. Nor can you control what happens on the other side of an embedded link or script. What if a server hosting an image on your site gets hacked? Will it cripple your site? Are they intercepting data? Will you know?
Sugar is extremely customizable by admins and developers. It is quite easy for an admin to add a link to an external image or custom script from a CDN. How do you control that?
Hackers have many motivations for manipulating websites. Not all hacking attacks are meant to be malicious to your site - but many (if not most) are. A common hack is to add malicious code to an insecure site that is embedded on the site already. This is called Cross-site Scripting (XSS). The attack doesn't have to come from something already on the page. XSS hacks often occur from inline scripts - or even inline CSS. Inline scripts and CSS can be inside of an HTML element's attributes like this:
<img src=x onerror=alert(1) style="background-image: url(http://an.external.site/script-that-returns-an-image)" />
Or, as a script block within the HTML like this:
Keeping track of all of the inline references in addition to the rest of your content can be very difficult. For this reason, most CSPs block all inline scripting and CSS - and, honestly, it is just a best practice to avoid inline scripting if possible. If your site needs to allow inline scripting, it can be enabled through the CSP header. Note that I mentioned CSS. An attacker could change your CSS to make your page appear completely differently than originally intended.
Regardless of the intent or method, no one should be manipulating your site other than you. In Sugar, that is very difficult to guarantee. By having a CSP in place, the browser will watch your site for you. It will not permit any external scripts, for example, that you have not allowed through the rules in your CSP. Kinda nice having the browser do the work for you huh? But note that all major browsers (Firefox, Chrome, Safari, Edge, et al) recognize, understand, and enforce a CSP, Internet Explorer does not.
So, how do you implement a CSP?
While a CSP can be set via HTML meta tags, it is much more common to set a policy via HTTP response headers. This usually requires setting your policies on your server. There are lots of HTTP headers that you can set to improve security, authentication, and other back-end services on your site. For this article, we are focusing on the Content Security Policy. So Let's take a look at one now.
Here is an example of a CSP response header: Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
You can see that our CSP is first defined by starting with Content-Security-Policy. Everything after the colon is a setting that we want to implement. Each individual setting within the policy must be separated by a semi-colon. Let's break down the settings in the example.
default-src 'self';- restrict all content to be served from internal domains (does not include subdomains). at a minimum this directive should be set as all other directives that are not defined will look to this setting.
img-src *;- allow images from anywhere
media-src media1.com media2.com;- allow videos and audio from media1.com or media2.com but no other external sources
script-src userscripts.example.com- allow scripts from userscripts.example.com but no other external sources
At SugarCRM we place a particularly high value on security. So, in order to continue to provide our customizable products safely, we will be implementing and enforcing a CSP in Sugar 11.0. Basically our default-src directive will be set to 'self' so as to block any external content from being served through the Sugar application. Adding this CSP will make Sugar less vulnerable to malicious hacks. It also means, however, that any existing content from external servers will be blocked.
An example of common content in Sugar that could now be blocked is an iframe. If you have an iframe dashlet on your instance of Sugar that is serving a page from another server, after 11.0 the dashlet will likely be blank or show an error.
Don't worry too much: we are adding a CSP Administration module to the Admin section of Sugar Sell/Serve/Ent/Pro. Here you will be able to make adjustments to the existing CSP by adding your own directives. This is how you can allow your iframes - a very common Sugar customization - to still behave as expected. By setting the specific directives, you will essentially be overriding the default-src directive with your custom exceptions. And that's what we are doing - adding exceptions through our CSP by telling the server that videos from media1.com should be allowed through.
To be clear: Sugar is not enforcing any CSP until version 11.0 at the earliest. I will ensure that I post a reminder prior to release and will highlight the change in the developers' webinars. Until then no action is required. After that, however, it will be important to test all of your integrations and customizations to ensure that nothing has been blocked and requires an exception to be added to the CSP.
A CSP can and will help you mitigate security vulnerabilities on your website. If this is a new concept to you, I encourage you to look into it more thoroughly. Find out how you can implement a policy for your site that fits your needs. A quick Google search will find you tons of resources - like The Mozilla Developers Docs - to dive deeper into CSPs.
For information on the new CSP admin module, view this related article.
