Question to the removal of source editing from the agent interface

[tipue-dev]

Hi,

Was the removal of source editing from the agent interface intentional? If so, would you be open to making it possible to enable it again through SysConfig? I would be happy to contribute a PR to make the agent toolbar configurable, if that approach would be welcome.

I’m referring to commit 382201d. The description specifically mentions disabling source view in the customer frontend, but the diff also removes sourceEditing from the agent toolbars in SetRichTextParameters.

Source editing is useful for some of our customers in the agent interface. I agree that the customer frontend generally does not need this feature. Since the commit description only mentions the customer side, could you clarify whether the removal on the agent side was also intended?

I’m also interested in the specific security reasoning behind this change. Removing the toolbar button does not prevent users from submitting arbitrary HTML through modified requests. The safe rendering should be and is there on the server side.

What additional protection does removing source view provide here? Does it address a specific execution path within the editor itself, or is it intended as an additional precaution against users inadvertently inserting unsafe content? Any context you can share publicly would be appreciated.

Thank you!

[hanneshal]

Hi @tipue-dev,

yes it was intentional. There where multipiple occasions where a non privieleged agent was able to insert wild code,
which then might be shown (or exactly not to be shown) to an admin user, which then may result in an attack.

And as we simply can not find all possible attacks possible that way, we went the sane way to remove this completly.

You can reintroduce those plugins if you like in an addon, but we had minor complaints about this.
Mostly related to the current paragraph setup, which we will address in one of the next releases.

Other than that I really do not see a usecase in Znuny tbh.
If you have valid usecases, let me know.

Regards
Johannes

[tipue-dev]

Hi @hanneshal,

Thank you for the clarification.
It is of course debatable what constitutes "valid usecases". We have customers, that use it to have more control over the signatures HTML for example. Since there is an update pending for them, there was an open question if we need a fix, or if we should wait for the next version.
But then we will reintroduce it with a plugin.

Could you clarify for me just that one point, you removed this to make it less inviting to add code to an article body, but there is no inherent difference in the attack vector, it is still just an article body with malicious code that is send as body payload, correct?

[hanneshal]

Could you clarify for me just that one point, you removed this to make it less inviting to add code to an article body, but there is no inherent difference in the attack vector, it is still just an article body with malicious code that is send as body payload, correct?

In fact there is a difference. The admin interface allowed far more editing (and less checks) for the RichText. Also Agents were able to modify quoted content in a reply - which got correctly stripped from the backend - and then stored and shown direclty. As I said, there were wild code blocks... Which you where not able to store / create using the regular editor.

[tipue-dev]

Hi @hanneshal,

i don't want to use too much of you time, but i hope you give me another minute, just to be clear in the problem you described.

If an Agent for example replaces the CKEditor by a textarea in it's own browser and pastes modified html into it, than the agent can send the exact payload he could have created using the CKEditor with source editing. Did you meant to make it harder for an attacker, so he must use a way, like i described, instead of using the source editing function?

The problem lies not in the CKEditors source editing itself, right?