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.
Here is an example of a secure CSP.
Content-Security-Policy: default-src 'none'; img-src *.images.example.com; media-src
media-server.com;script-src apis.example.com; style-src 'self'; object-src 'none';
frame-ancestors 'self'; upgrade-insecure-requests;report-uri https://example.com/cspreports/
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
• 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
• 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.
Discuss your pilot or production implementation with other Zimbra admins or our engineers.
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 13 guests