Use nonces on autologin links?

Hi @tezalsec

In order for this attacker to be performed, full access to the MainWP Dashboard would be necessary. So a predictable link to the Child Sites would not be enough to perform the attack.

And the communication between the Dashboard and Child Sites is encrypted with OpenSSL to prevent snooping.

You can find out more information about the communication at this link:
https://kb.mainwp.com/docs/mainwp-dashboard-child-synchronization-process-explained/

Hi Bojan,

your response is not a comforting one, since nonces are designed exactly to protect situations like I am describing (CSRF), where an authenticated user is tricked into clicking a link, unwillingly performing an action that makes changes to the site.

Example:
https://css-tricks.com/wordpress-front-end-security-csrf-and-nonces/

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 the value 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 Bogdan,

Great, thanks for the elaborate response!

Cheers!