Page 1 of 1

Missing Content-Security-Policy Header

Posted: Thu Jan 24, 2019 12:38 pm
by yasanthau

Upon a vulnerability scan, it is requested to fix the above issue on Zimbra Server (8.8.7_GA_1964.RHEL7_64_20180223145016 RHEL7_64 FOSS edition). Please refer the details below.

The zimbra server does not set the Content-Security-Policy (CSP) header in HTTP responses, and, therefore, the application is at a greater risk of having cross-site scripting or other modern application vulnerabilities. The CSP header sets a policy that instructs the browser to only fetch resources, such as scripts, images, or objects, from the specified locations. A compliant browser will deny loading any resources from locations not listed in the policy.

CSP allows browsers to differentiate between trusted and untrusted content requested by the page. By default, it also prohibits inline script execution, as well as dynamic script evaluation. When implemented correctly, the CSP reduces an attacker's ability to inject malicious content and helps protect a web page from attacks like cross-site scripting (XSS), dynamic code execution, clickjacking, remote file inclusion (RFI), and others. The CSP adds an additional line of defense and reduces the overall security risk.

The application server must set the Content-Security-Policy (CSP) header in each HTTP response with the appropriate directives defined to provide the browser with granular control over the resources loaded by the application. Implementing a CSP should be considered a security best practice as part of a larger defense in depth strategy to reduce the risk of various attacks. CSP alone should not be relied on to prevent attacks such as cross-site scripting, dynamic code execution, clickjacking, remote file inclusion, or other injection attacks. To implement a secure CSP, the application would need to use no inline <script> tags. This often means a rewrite of the whole client side application using one of the CSP-compliant JavaScript frameworks. Otherwise, CSP will block normal execution of the application. Note that setting the script-src directive to 'unsafe-inline' allows execution of any JavaScript injected by an attacker, as well as the execution of legitimate JavaScript.
Here is an example of a secure CSP.
Content-Security-Policy: default-src 'none'; img-src *; media-src;script-src; style-src 'self'; object-src 'none';
frame-ancestors 'self'; upgrade-insecure-requests;report-uri
CSP has a lot of different directives and settings. Here are some best practices to create a strong security policy:

• Specify a default policy. It is recommended to set it to 'none'.
• Specify a whitelist of sources for script-src and object-src directives.
• Avoid setting default-src and script-src to 'unsafe-inline' or data:. The 'data:' URIs can be
used to inject and execute JavaScript.
• Avoid setting default-src and script-src to 'unsafe-eval'. The 'unsafe-eval' policy allows the
use of eval() and similar methods which can be abused for code injection.
• Avoid setting script-src or default-src to 'self' for hosts containing Angular applications,
JSONP endpoints, or files uploaded from users, as attackers can manipulate such
applications to execute attacker's code uploaded to the application's host.
• Avoid setting the object-src directive to *, as it allows loading of arbitrary plugins that can
execute JavaScript.
• Only use third-party URIs that start with https:, as content loaded over HTTP can be
modified by an attacker.
• Set the frame-ancestors directive to specify sources from where the current page can be
framed or set it to 'none' to avoid clickjacking.

Any solution to this issue is highly appreciated.