CSP for Zimbra 8.7.3

[cr.ionita]

Hello,

Can anyone help me set a Content Security Policy for Zimbra OSE 8.7.3?

Thanks!
Cristian

[ExTechOp]

Can anyone help me set a Content Security Policy for Zimbra OSE 8.7.3?

We've just on Friday upgraded to Zimbra 8.7.3_GA_1750 (build 20170215042321) and the Zimbra document Security Settings for Zimbra Collaboration 8.7 series gives some good hints on setting up ciphers and the extra security headers for the server. It also provides a link to Content Security Policy header generator but implementing this to good effect would really require understanding the internals of Zimbra much better than I do. I think Zimbra should supply a ready set, since they obviously know these things.

Observatory by Mozilla is a good tool to check these settings out.

[ExTechOp]

We've just on Friday upgraded to Zimbra 8.7.3_GA_1750 (build 20170215042321) and the Zimbra document Security Settings for Zimbra Collaboration 8.7 series gives some good hints on setting up ciphers and the extra security headers for the server. It also provides a link to Content Security Policy header generator but implementing this to good effect would really require understanding the internals of Zimbra much better than I do. I think Zimbra should supply a ready set, since they obviously know these things.

Observatory by Mozilla is a good tool to check these settings out.

Also, just today I've discovered bug #107672 in Zimbra which will make adding the headers a bit painful before it gets fixed. There's also the quite old bug #58216 which essentially asks Zimbra to implement Content Security Policy headers, please upvote it.

[L. Mark Stone]

Old thread I know... but just in case folks are Googling for Zimbra CSP or Zimbra Content Security Policy there is this Certified wiki documentation with several links to Content Security Policy resources at the bottom.

https://wiki.zimbra.com/wiki/Security/Collab/88

Hope that helps,
Mark

[ExTechOp]

Now that bug #107672 is history, so it is possible to set the Content-Security-Policy header on nginx. Unfortunately, the best I could come up was

Code: Select all

Content-Security-Policy: "default-src 'none'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; connect-src 'self'; img-src 'self' data:; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'; style-src 'self' 'unsafe-inline'; form-action 'self'; frame-ancestors 'self'"

If you run Mozilla Observatory on the server, you get the complaint:

Content Security Policy (CSP) implemented unsafely.
This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-src or script-src.

Does anyone who actually understands the issues have more comprehensive suggestions?

[JDunphy]

Now that bug #107672 is history, so it is possible to set the Content-Security-Policy header on nginx. Unfortunately, the best I could come up was

Code: Select all

Content-Security-Policy: "default-src 'none'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; connect-src 'self'; img-src 'self' data:; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'; style-src 'self' 'unsafe-inline'; form-action 'self'; frame-ancestors 'self'"

If you run Mozilla Observatory on the server, you get the complaint:

Content Security Policy (CSP) implemented unsafely.
This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-src or script-src.

Does anyone who actually understands the issues have more comprehensive suggestions?

I don't claim to understand this but after reading this paper last year... https://storage.googleapis.com/pub-tool ... /45542.pdf and how easy it is to bypass CSP, I have come to the conclusion that a nonce based policy is the direction I would like to see and is the direction I am heading with our projects. Briefly.

In a nonce-based policy, instead of whitelisting hosts and domains for script execution, the application defines a single use, unguessable token (nonce) delivered both in the CSP policy and as an HTML attribute of legitimate, application controlled scripts. The user agent allows the execution only of those scripts whose nonce matches the value specified in the policy; an attacker who can inject markup into a vulnerable page does not know the nonce value, and is thus not able to execute malicious scripts.

I was using this as my guideline. https://csp.withgoogle.com/docs/strict-csp.html but wish I had a better understanding of the risks with Zimbra. Note my approach thus far as been to make sure protocol downgrade attacks couldn't occur as my highest priority. We have also added a custom icon on the login page and different icon after login in attempts to mitigate this further and do follow the guidelines to the link you already mentioned. I should note that the mozilla observatory rates google as a D even with nonce based CSP+. Thank you for attempting to push this forward. There needs to be a lot more done.