Notice: This thread is over two years old; the information may be outdated. Please consider creating a new thread if you require free support. If you have an active SiteOrigin Premium license, you can email our premium support desk at [email protected].
Hi,
I’m having problems with cloned pages. I have recently (27 August) made a new page by cloning an older one. At first, there was no problem editing it, but today I get a 403 warning:
“Forbidden
You don’t have permission to access this resource.”
I can edit all other pages, including ones that have been made by cloning before, and I can make completely new pages. But I cannot edit this page and I can also not make a new page by cloning.
site: korthagen.nl
Can you help me out?
Thanks in advance,
Joost
Hi Joost
Thanks for posting.
Please, try contacting your hosting company, let them know the issue and ask if they can please, check the ModSecurity logs for your site. It’s possible that a ModSecurity false positive is the problem.
Hi Andrew,
I found some clues online in that direction and have already contacted them. I will keep you posted whether this is the solution.
Thanks for now!
Joost
Thanks, please, let us know how it goes.
You can also try checking for console errors as the issue occurs. Here is how: https://wordpress.org/support/article/using-your-browser-to-diagnose-javascript-errors/#step-3-diagnosis
Hi Andrew,
I’ve heard from the host and they ask me to get back to you. No false positive, they say.
As for the console errors: during the process of trying to publish a page, resulting in the error, I get these notifications:
MouseEvent.mozPressure wordt niet meer ondersteund. Gebruik in plaats daarvan PointerEvent.pressure. tinymce.min.js:2:9046
MouseEvent.mozPressure wordt niet meer ondersteund. Gebruik in plaats daarvan PointerEvent.pressure. tinymce.min.js:2:9046
[Exception… “Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIContentSniffer.getMIMETypeFromContent]” nsresult: “0x80040111 (NS_ERROR_NOT_AVAILABLE)” location: “JS frame :: resource:///modules/FaviconLoader.jsm :: onStopRequest :: line 230” data: no] FaviconLoader.jsm:230:24
onStopRequest resource:///modules/FaviconLoader.jsm:230
InterpretGeneratorResume self-hosted:1284
AsyncFunctionNext self-hosted:839
Does this help in any way?
Joost
Hi Joost, unfortunately, nothing helpful there that I can see. Please, could you try running a plugin conflict test and then replicating the issue. The goal is to see if a working baseline can be found. Please, see below.
This sounds like it could be a plugin conflict issue. Can you try disabling all non-SiteOrigin plugins and see if this fixes the issue? You’ll need to clear all your caches after disabling your plugins.
If it does fix the issue, then try re-enabling your plugins one by one until the issue comes back. This procedure will help diagnose which plugin is causing the issue.
Once we know that, we’ll be able to look at what might be causing the conflict and either solve the problem or help you find an alternative plugin.
If you aren’t using a SiteOrigin theme, then you can also try temporarily switching to one of the default WordPress themes to see if the issue is theme related.
New information from the host: they’ve established that it is definitely something in the plugin code that is being blocked by Comodo WAF. See the log:
[Thu Aug 29 17:02:22.940884 2019] [:error] [pid 2724734:tid 140167036999424] [client 145.133.106.173:55524] [client 145.133.106.173] ModSecurity: Access denied with code 403 (phase 2). Pattern match “http://[a-zA-Z0-9._]{1,}?/.{0,}?\\\\.pdf\\\\b[^\\\\n\\\\r]{0,}#” at ARGS:panels_data. [file “/usr/local/cwaf/rules/08_Global_Other.conf”] [line “21”] [id “211050”] [rev “1”] [msg “COMODO WAF: Universal PDF XSS URL Detected.||korthagen.nl|F|2”] [severity “CRITICAL”] [tag “CWAF”] [tag “Other”] [hostname “korthagen.nl”] [uri “/wp-admin/post.php”] [unique_id “XWfo-gGSnHze6EYYdgeaYwAAABE”], referer: https://korthagen.nl/wp-admin/post.php?post=4843&action=edit
Can you establish whether it’s a dangerous exploit, or a false positive? If the first, could you fix this, if the latter, could you report this to Comodo?
Thanks,
Joost
Thanks for the update.
This appears to be the rule:
http://[a-zA-Z0-9._]{1,}?/.{0,}?\\\\.pdf\\\\b[^\\\\n\\\\r]{0,}#Is there a link to a PDF on the problem page? The rule appears to be blocking any link to a PDF, assuming we’re reading that correctly. So yes, based on these assumptions, it’s a false positive.
Yes, there is a pdf.
Can you inform Comodo of this? The host is reluctant to do so, as they do not now the code of your plugin.
now = know
Super, glad we’re making progress. We’re here to help wherever we can but this is really a hosting level issue. All of Page Builder’s code is public on GitHub, we’d be happy to assist if a specific problem is raised but that doesn’t appear to be the case here. Are you able to work around the rule? Try downloading the layout you want to use from LayoutsImport/ExportDownload Layout. On your target page, import the page via the same method. Any change? If not, try removing the link, cloning the page and then inserting the link back into the page. Does that help?
Hi Andrew,
No, none of this works. I can’t export layouts as long as there are pdfs in them, I can’t save anything as soon as I’ve put the pdf back into the page.
Does the issue persist if you use a similar link in a classic page without Page Builder?
Strangely enough, I have been able to create a new page, with pdf's, in
Page Builder. That I can publish and edit.
I can also clone it, and edit tte new page.
But I can't edit most existing pages with a pdf in it, it seems especially if they have been cloned.
Creating a classic page as you asked, without Page Builder and with the same pdf links, is also possible.
Thanks for confirming.
There isn’t anything that I can offer from our side, I really wish there was. Your server is actively blocking those pages because of their contents. This would appear to be a classic case of ModSecurity false positive. I’m not sure why they’d have a rule targetting PDF links, I don’t understand why that’s the case. The rule seems to be completely illogical, at least given the information I have to work with.
Your hosts have opted to use https://waf.comodo.com/ for their ModSecurity rules. Try going back to them, it’s their choice to use Comodo for these rules, you’re seeing a false positive and need a change made.