Webhook error

Bob Bundy are you working with a Sugar Partner? A partner would be able to help you write custom logic to send the data to your downstream system. You can also use an iPaas solution such as Sugar Integrate to solve your issue.

After a quick investigation I identified the issue within. Fortunately it is possible to fix that in an upgrade safe and packageScan safe way until SugarCRM provides a final solution.

Let me know if you are interested on such a solution.

Regards

Hi Bob Bundy

The external calls could be configured in Logic Hooks - which, IMHO, provides more flexibility and adaptability than Web Logic Hooks - who knows, maybe this fact has been taken into account when the issue received its severity...

Have a look:

If 100MB+ is not a healthy amount of data to be sent for your case, the middleware might not be mandatory,
and I would assume that it should be possible to configure expected behavior in Sugar  with the Logic Builder no-code configuring tool

Here is how solution configuration looks in Logic Builder for the example on the video - send JSON with POST to the given URL on record edited (or added - see the "new" -boolean output for the first operator in the flowchart below? - zoom in and follow the white line to read the flowchart).




The tool provides an installable zip for the flowchart - in a click, then I deployed it to Sugar demo instance.
So in total, it took for me approx 5-7 min to design it + 5 min to deploy it to Sugar via Module Loader and another 10 to make a video provided above :)

If you would like to try the approach for your case, the solution will cost you nothing but genuine Sugar subscriber's feedback here, in the Club, whether configuring with Logic Builder helps.

If you like to make logic hook work for your Sugar on these conditions, pls drop me a line at dch@integroscrm.com and let me try to help :)

Hi Bob Bundy

This ticket is currently going through our QA process and will be released ASAP. Thanks for your patience on this one!

Hannah @ SugarCRM

Thank you Hannah Sutor.  I'll be excited to get this so we can go live.

I reported the bug as a security bug 1.5 years ago.
Examine the 100MB data sent out and you will know why.
I guess we should be happy that it is already being worked on. There are security related bugs that have waited even longer for a fix after internal disclosure. See their security advisories to see how fast security related bugs are fixed after (internal) disclosure.

This is an excellent observation and a valid question and concern.

The data does contain a security vulnerability. The important distinction though is between a vulnerability and a risk level/threat level. The risk level is Very Low.

The fact that this breaks Web Logic Hooks is more critical than the security aspect, and the fact that web hooks are in relatively low use and less-used when broken ends up causing the risk level to be even lower. Together these factors resulted in lower priority of the bug at the time it was reported.

Specifically, the only risk factor we are aware of in this particular bug is a breach of trust on the transport to the web hook's fielding server and on that server itself. The feature can only be enabled by admins on the Sugar instance, and an admin has access to other methods of acquisition of the released data that are much easier. 

Not all bugs are of equal importance, and this applies to security bugs as well. A security bug with a low or zero risk is not priority or may not be fixed at all depending on the tradeoff costs.

A person's elbow is vulnerable to injury. That is a vulnerability. If there is a higher risk (sports, for example), then fixes (pads) would be applied. However most humans have unpatched (unpadded) elbows due to a low risk level and the tradeoff cost (lack of flexibility, cost of the pads, odd looks) of wearing elbow pads everywhere.

If you are aware of factors that would increase the risk level - for this or any other security issue you have reported or are aware of -  we will always accept that information and add it to our assessment, then take action as needed.

We take security seriously, and security is a balance. If a security bug has a high risk level or is a substantial threat, then it is address quickly and hotfixed in many cases. If you don't see movement on a security concern, our analysis considers it to be as much risk to SugarCRM users as a bare elbow is a risk of injury to an average person.

Do I wait and hope to get my post verified, which was flagged as spam/abuse or do I write it again with less data ... 

Again, what you are telling is just marketing blaah. The facts telling another story:

https://support.sugarcrm.com/Resources/Security/sugarcrm-sa-2021-001/  risk level High - 1253 days
https://support.sugarcrm.com/Resources/Security/sugarcrm-sa-2021-003/  risk level High - 716 days

My other post which was flagged, contained a list of all sugar security advisories since 2016 and the time span between disclosure and possible some kind of public disclosure/fix. If you create the table for yourself, you will see that the average time span increased a lot over the years.

Those two were flagged by the automated system (I don't have access to that, so I can't speak on the matter with authority), but I did get the information itself.

I'd be happy to discuss this with you directly rather than hijacking this thread.

I don't think discussing with me solves the problem of too less developers, who care about  bugs and security issues.
It would be more effective to make this problem clear to your management, so that more developers are appointed to these unpopular topics.

And by the way, please stop starting your release text with sentences like this:

"At SugarCRM, we take seriously the security and the protection of your systems and data."