More XSS vulnerabilities: vote for content-security-policy

[halfgaar]

Zimbra 10.1.19 fixes another critical XSS bug (and note, this fix is not yet in the open source builds, because of the embargo):

https://blog.zimbra.com/2026/07/patch-r ... a-10-1-19/

There is a request at pm.zimbra.com to implement Content-Security-Policy:

https://pm.zimbra.com/p/zrfe-44-support ... ity-policy

A bit redundant/repetative perhaps, but I call on people to upvote or comment on the issue. It is a far better solution than the endless whack-a-mole that's going on now.

Also, it's important to note that with AI, the undiscovered cases of unescaped user input are easily found. All the more reason for a good Content-Security-Policy header.

[liverpoolfcfan]

There is a request at pm.zimbra.com to implement Content-Security-Policy:

https://pm.zimbra.com/p/zrfe-44-support ... ity-policy

A bit redundant/repetative perhaps, but I call on people to upvote or comment on the issue. It is a far better solution than the endless whack-a-mole that's going on now.

If you have Up-Voted it before, if you click Up-Vote it will remove your existing vote and you can re-Up-Vote it. Doing so will allow you to select a priority level for the suggestion where you can flag it as "Critical"

[JDunphy]

They need to do it and do it quickly.

That we are still having to vote on it says they really don't understand how bad an idea it is to leave sanitization as the only line of defense for untrusted html. You tried in a previous thread and I tried with modsecurity and lua but that complexity wasn't going to work for anyone but developers without their cooperation given the way they roll out patches.

About 7-8 months ago, I went another route and that was to bring Zimbra Web Client (ZWC) to a high performance proxy written in Rust that ran in a docker container. If they won't fix their technical debt in mailboxd then we bring it to us and fix it there with injection given I treat those ZWC static assets as immutable.

What I ended up doing was iframe containment for the rendering iframe AND a different document object to change the trust boundary for reading email vs the App shell for the ZWC. That allows the iframe to have a strict CSP and render in a sandbox. I also did proper html sanitization with ammonia given I was not happy at all with how they handle CSS with one tool and html with another and are often tricked especially with CSS methods. I also piled on the security layering such as an image proxy to harden that CSP and add additional privacy protections.

I did try a strict CSP on the whole app shell but that is architecturally impossible IMNO because of things like: zimbra/js/ajax/boot/AjxPackage.js which fetches JS packages over XHR and executes them in the global scope via browser-specific eval-equivalent fallbacks. The entire application boot process depends on this pattern. Any CSP under which ZWC boots must include 'unsafe-eval' ... not to mention UI templates are compiled at runtime. Template compilation (ZmSearch.js and many others) generates functions from strings at runtime. Also requires 'unsafe-eval'. Inline script is everywhere (31 inline <script> blocks across 14 JSP/HTML files, etc, etc.

Unfortunately, I wrote this as a fallback project initially because FOSS was not getting security updates and I needed a different fallback if it wasn't going to be the FOSS version of the product. It works with JMAP, JMAP PUSH and a different backend. I either have to port JMAP to mailboxd as an extension or add a different backend to this bridge/proxy.

Jim

[halfgaar]

(I didn't get an e-mail about new posts in this thread btw. E-mail notifications may be broken)

If you have Up-Voted it before, if you click Up-Vote it will remove your existing vote and you can re-Up-Vote it. Doing so will allow you to select a priority level for the suggestion where you can flag it as "Critical"

Done. I also had left another reply, which was just approved.

They need to do it and do it quickly.

...

That's quite some extra effort you put into it. I gave up after last time.

It'd be interesting to hear about Zimbra's efforts or opinions on this matter. They would be in a better position to know how much work it is when approached throughout the whole stack, instead of an end-of-pipe solution like what we've tried.

[darkfader]

"We recognize the value and potential impact of this feature and have added it to our pool for consideration in upcoming development sprints. It will be prioritized based on overall reach and impact alongside other requests."

I'm gonna try that reply on the next reminder for my taxes, lets see how it goes.

IOW: Zimbra, you don't need to prioritize this. You need to increase whatever man-hours you have planned yearly for security refactoring and add the headcount dedicated to it, have that report to your board and build a different decision process for security refactors. You also need to add manpower for solving problems that may arise while hardening zimbra.
you also need to add manpower to have more QA while hardening and for the future.
All of that will be people who have some spare time as they work on this, and what they do in that spare time (on product features),, that you can prioritize and consider to put onto sprint planning.
You can't forever just rest calmly on the fact that your customers haven't sued before and won't sue later.
Currently, people can either migrate away or pray, but i.e. from an insurance POV running Zimbra is not a mild risk.
It could be. It could have a much better posture than most systems, all that's missing is _doing_ more.

[adrian.gibanel.btactic]

Does anyone know if these kind of problems just disappear if classic ZWC is left behind and only Modern UI ZWC is used?

Because if that's the case there you have your answer on why this keeps postponed by Zimbra themselves...

Classic ZWC is meant to be EOL soon.

[jered]

Does anyone know if these kind of problems just disappear if classic ZWC is left behind and only Modern UI ZWC is used?

Because if that's the case there you have your answer on why this keeps postponed by Zimbra themselves...

Classic ZWC is meant to be EOL soon.

Theoretically; I'm not aware of XSS vulnerabilities being reported against the Modern UI.

But the Modern UI is entirely closed-source.

[halfgaar]

Does anyone know if these kind of problems just disappear if classic ZWC is left behind and only Modern UI ZWC is used?

Because if that's the case there you have your answer on why this keeps postponed by Zimbra themselves...

Classic ZWC is meant to be EOL soon.

The modern UI is written in Preact. This has some facilities to auto escape printed text, but it doesn't make you immune to still manipulating the HTML. So, a good content security policy is still required.

It seems Preact makes it easier to write code that doesn't require in-line scripts, so if they indeed avoided that, it would be a lot easier to set a content security policy.