SiteOrigin / SiteGround 400 Error Issue

Hi, good to hear from you. Thanks for your kind feedback.

This is a new one for us, as far as I’m aware. Might it be possible to run a quick plugin conflict test with all plugins except for Page Builder temporarily deactivated? I forget if SiteGround Optimizer is a plugin or a Must-Use or Drop-In. If that could be deactivated (if possible) for the test, that would be great.

Hi,

I deactivated all plugins except the SiteOrigin and added them back one-by-one, testing the page preview and updating each time.

All-in-One SEO (AIOSEO) is the culprit. Now the odd thing is that this 400 Error issue ONLY happens with SiteGround hosting.

I will reach out to their support team.

Thank you!

Thanks for the update. Does the issue persist with only Page Builder and All In One SEO activated?

Hi, Yes it does. Here is the SiteGround support reply on the issue:

I was able to recreate the issue successfully on the page you mentioned. Upon further investigation, it seems like a mod_security rule is being triggered by the editor in question:
2023/03/07 23:00:24 [error] 93448#0: [2023-03-07 23:00:24+0000] [beta.speechworks.net/sid#0000000] [client 87.118.135.66] ModSecurity: Access denied with code 400 (phase 2). detected XSS using libinjection. [file “/etc/nginx/modsec/rules.conf”] [id “807086”] [msg “”] [data “”] [severity “0”] [hostname “35.209.87.233”] [uri “/wp-admin/post.php”]

I have excluded the rule in question for your site just now and the page preview option is now working properly:

https://clb.sh/f3cbfd

The same goes for the update option:

https://clb.sh/c103b7

If you wish, you can report this to the developers of the plugin so they can possibly address this. You can provide them with the log from our mod_security log to provide further clarity on why the request is getting blocked by our mod_security module.

For even further clarification on the rule and why it was implemented, it was related to the following vulnerability:

https://www.wordfence.com/blog/2023/02/all-in-one-seo-pack-vulnerabilities-impacting-3-million-sites-patched/

This is somehow put in the request when updating and previewing the image but I am not quite certain how. This is something that would be best discussed with the developers of the SiteOrigin plugin and whether they have some sort of way to address this. Alternatively, you can also contact the support team of the AIOSEO plugin to discuss this with them also.

Hi, Yes it does. Here is the SiteGround support reply on the issue:

I was able to recreate the issue successfully on the page you mentioned. Upon further investigation, it seems like a mod_security rule is being triggered by the editor in question:

2023/03/07 23:00:24 [error] 93448#0: [2023-03-07 23:00:24+0000] [beta.speechworks.net/sid#0000000] [client 87.118.135.66] ModSecurity: Access denied with code 400 (phase 2). detected XSS using libinjection. [file “/etc/nginx/modsec/rules.conf”] [id “807086”] [msg “”] [data “”] [severity “0”] [hostname “35.209.87.233”] [uri “/wp-admin/post.php”]

I have excluded the rule in question for your site just now and the page preview option is now working properly:

If you wish, you can report this to the developers of the plugin so they can possibly address this. You can provide them with the log from our mod_security log to provide further clarity on why the request is getting blocked by our mod_security module.

This is somehow put in the request when updating and previewing the image but I am not quite certain how. This is something that would be best discussed with the developers of the SiteOrigin plugin and whether they have some sort of way to address this. Alternatively, you can also contact the support team of the AIOSEO plugin to discuss this with them also.

• This reply was modified 1 year, 8 months ago by twowithink.

Thanks for the detailed feedback and reports. I’m glad to hear you’re making progress and that SiteGround support was able to promptly help with the investigation.

Cheers for now.

Andrew

Hi Andrew,

So, from the report from SiteGround, you feel that the flagged mod_security rule has nothing to do with SiteOrigin page builder? Even though this only happens with the AIOSEO plugin activated, it does only occur if a layout value (padding, margin, etc.) is added to a SiteOrigin row.

Thanks,

I’ll ask Alex to take a look to see if there is anything that can be done from our side. Thanks

Hi,

This is a tricky one. It’s not immediately clear why this rule is being triggered. This is likely a bit of a stretch, but would it be possible for you to request the full rule that’s being flagged? This is different to the log and it will provide more insight into why it’s being flagged as we can see the specific pattern they’re looking for. This looks to be a custom rule so it’s possible they may decide not to share it and that’s understandable.

Kind regards,
Alex

Hi,

Here is SG’s reply:

This rule was indeed implemented due to a quite recent vulnerability of another plugin – All In One SEO Pack.

https://www.wordfence.com/blog/2023/02/all-in-one-seo-pack-vulnerabilities-impacting-3-million-sites-patched/

The rule is up to date and our security team is constantly adjusting the rules to prevent attacks. If you wish, we can enable the rule again so you can continue debugging the issue with the plugin developers.

I replied:

So you are saying that All In One SEO Pack has not addressed the vulnerability issue to your liking? They claim to have fixed it in v. 4.3+

SG response:

We are not familiar with the All In One SEO Pack plugin and its updates but our mod security rule is triggered by the site. We can enable the rule back so you can test the site if you wish, however, the rule cannot be adjusted on our end. Our security team periodically reviews the rules and adjusts them when needed.

Hi,

Thanks. That appears to be a response to why the rule was added rather than the rule itself. Can you please try requesting the rule again directly again? Regardless, I’ll run some tests on our end to see if I can spot what they may be flagging.

Kind regards,
Alex

Hi Alex,

I have asked SiteGround and will update you with any response. AIOSEO support have also indicated they are looking into the issue.

Thanks.

Hi,

SG reply:

I can see that my colleagues have already provided all available information regarding the mod_sec rule triggered.

I am afraid that we cannot provide any additional information, but hope you will manage to find and resolve and possible culprits as swiftly as possible.

Hi,

Thanks for trying. I don’t blame them for not wanting to supply the rule. It does however make identifying what is going on quite tricky. I’ll run some tests and try to identify what could be causing this but I suspect this may not be something we can reliably resolve without knowing specifics (it’s quite a gap in knowledge and filling it is going to be difficult).

Kind regards,
Alex