Bogdan Rapaic
Forum Replies Created
-
Hi,
We have been trying to duplicate this problem on our test setups, but we couldn’t.
Can you please open a helpdesk ticket so we can look further into this?Hi @maks131313,
We appreciate your feedback, but @bojankatusic already mentioned in your helpdesk ticket that MainWP still does not support PHP 8.1. At this point, we can’t troubleshoot issues on unsupported PHP versions.
(On a side note, we plan to implement 8.1 support soon, but I don’t have an exact ETA again.)
Also, I reviewed your helpdesk ticket, and we are still waiting for your feedback on the questions and instructions we sent.
Since you have a helpdesk ticket open, let’s not run this troubleshooting process in multiple channels, it just slows the process and makes it harder for all of us. If it’s ok, let’s continue in the helpdesk.
We will be sure to post our findings here once we figure out what is going on.
Thanks
Hi @mossifer,
We received your response in the helpdesk ticket, and I provided you with the answer.
As per the response code that you get from the child site in the problem, it’s evident that some security rule is blocking requests from your MainWP Dashboard.
Without the access we requested to look at it we are just chasing ghosts at this point, if you want us to investigate deeper we’ll need the access we requested.
Hi @ispacecrusader,
Can you please show them the response code and have them double-check?
Hi @mossifer,
The problem that you have reported may not be related to this one.
In this case, we have explicit confirmation that Cloudflare is causing the problem.
Hi @mossifer,
Thanks for reaching out.
You said you didn’t change anything on the server side, but as you saw earlier, problems were resolved by themselves.
To be precise, problems started without any change in the MainWP code and were resolved. Now it happened again without any change to the MainWP code.???????This means that something is happening on the server side; there could be multiple causes, performance issues, networking issues, glitches in the security layers, or just glitches with particular services on the server.
I would strongly recommend contacting your host support and having them review all server logs and see if anything jumps out.
Our offer still stands to look at the sites for you if you choose to give us the access we asked for in the support ticket you have on our help desk.
HI @ispacecrusader,
It is very possible that your host is using some CF service. Let us know how it goes.
Hi @ispacecrusader,
Regarding the original issue with the connection to the child site, I noticed that the Error message that you get also shows you the response code:
<!doctype html> <html> <head> <meta charset=”utf-8″> <meta name=”robots” content=”noindex, nofollow”> <title>One moment, please…</title> <style> body { background: #F6F7F8; color: #303131; font-family: sans-serif; margin-top: 45vh; text-align: center; } </style> </head> <body> <h1>Please wait while your request is being verified…</h1> <form id=”wsidchk-form” style=”display:none;” action=”/z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f” method=”get”> <input type=”hidden” id=”wsidchk” name=”wsidchk”/> </form> <script> (function(){ var west=+((+!+[]+!![]+!![]+!![]+!![])+(+!+[]+!![]+[])+(+![])+(+!+[]+!![]+!![]+!![]+!![]+!![]+!![]+[])+(+![])+(+!+[]+[])+(+!+[]+!![]+!![]+!![]+!![]+!![])), east=+((+!+[])+(+!+[]+!![]+[])+(+![])+(+!+[]+!![]+!![]+[])+(+!+[]+!![]+!![]+!![]+!![]+!![]+!![]+!![])+(+!+[]+!![]+!![]+!![]+!![]+!![]+!![]+!![]+[])+(+!+[]+!![]+!![]+!![]+!![])+(+!+[]+!![]+!![]+!![]+!![]+!![]+!![]+!![]+!![]+[])), x=function(){try{return !!window.addEventListener;}catch(e){return !!0;} }, y=function(y,z){x() ? document.addEventListener(“DOMContentLoaded”,y,z) : document.attachEvent(“onreadystatechange”,y);}; y(function(){ document.getElementById(‘wsidchk’).value = west + east; document.getElementById(‘wsidchk-form’).submit(); }, false); })(); </script> </body> </html>` `
If you take this code to codepen.io and render it, you will notice that this is some security layer that says: Please wait while your request is being verified…
After doing quick research, this seems to be Cloudflare bot protection that got triggered and started blocking Requests from your MainWP Dashboard.
Please review your Cloudflare settings and add your MainWP Dashboard IP address to the Cloudflare whitelist, so all requests from your dashboard bypass the Cloudflare checks.
Hey @tezalsec,
I understand your concern, but let me try to provide more info here.
That type of attack is extremely hard to perform.
Even though there is no nonce to verify, before the request is sent to a child site, the MainWP Dashboard escapes attributes to make sure that there is no harmful code passed in it.
This means that if the targeted child site is not previously compromised with custom code made by the attacker, there are no security risks.
In another scenario, if the targeted site is pre-compromised, it would be possible to execute an attack after the dashboard cleans the request, but this opens a new question, why would an attacker do that if he already has access to the child site?
You can see here that the
name
and thevalue
attribute values are escaped. So, even if someone does know your MainWP Dashboard URL, and tricks you into clicking a link that contains a malicious code, your Dashboard would escape it before it runs the redirection process, and there is no malicious code that can hit your child site.To be precise here, clicking a link like this: https://example.com/wp-admin/admin.php?page=SiteOpen&newWindow=yes&websiteid=1 does not hit the child site directly. This triggers the
open_site_location()
function in the MainWP Dashboard which first escapes attributes and then triggers the redirection to the child site.The request is “cleaned” before it goes to the child site.
To do any harm, a potential attacker would have to:
- Know that you use MainWP
- Know your MainWP Dashboard URL
- Know your email or something to reach you
- Trick you to click a link while you are logged into your MainWP Dashboard and the browser is open
- And the BIGGEST point, already have access to the child site that they want to attack
However, even though it’s not an easy attack there is still a non-zero chance that all those requirements could be met to perform an attack. And, even though we don’t consider this a real security risk, we still want to add an additional security layer.
After a meeting with the development team, the decision has been made to add the additional nonce verification layer. We have it scheduled for the next release.
We consider security a top priority! That said, let me stress that MainWP has had an open bounty program on hackerone.com/mainwp/ for years where we had multiple security experts review our code in order to find any potential security problems.
Here is a Knowledge Base article for additional reading.
Thanks!
- This reply was modified 2 years, 5 months ago by Bogdan Rapaic.
Hi @pidengmor,
Thanks for reaching out.
MainWP is PHP 8.0 compatible. We are running our test and dev setups on PHP 8 and we can’t duplicate this problem.
It is very strange that it occurs on 1 site and not on the other sites on the same server.
Can you try to completely delete the child plugin and try to install a fresh copy? It crossed my mind that the plugin file could get corrupted when you tried to install it for the first time.
Let me know how it goes.
Hi @momo-fr,
thank you for reaching out.
We are running out test & dev setups on PHP 8 servers and we can’t duplicate this problem. Updates and syncing sites works just fine.
Can you please verify that other plugins on the site are PHP 8 compatible and not causing errors that could affect your sites performance and conflict with other plugins?
Thanks
Hi @sanyadolpins,
thanks for reaching out.
The error that you get usually shows when the child site is already connected, so it’s required to deactivate and reactivate the MainWP Child plugin and try to connect it to your dashboard after that.
However, if the problem continues, it could be that some other plugin on the child site is causing some kind of a conflict so it would be good to try to connect the site with all plugins except for the MainWP Child deactivated.
Let us know how it goes.
Hi @gujingc,
thanks for reaching out.
Please see here our help document about the MainWP WP Multisite compatibility.
After further investigation in helpdesk ticket #8199, we found that some security rule on the child sites side blocks requests and returns the HTTP Error 403 – Forbidden.
The user has been advised to rule out all security layers to find which one is causing the connection problems.
Hi @hilleecz,
I see that you are using some security plugins on the Dashboard site which makes me think that there is some security rule on the site that blocks requests from your child sites to download images.
Can you please try to temporarily disable all security and caching plugins and see if that helps? If it doesn’t help, can you please check the server firewall log and make sure there are no blocked requests from IPs of your child sites.