Toegang geweigerd fout bij het aanpassen van sommige site-teksten

[jordan-violet]

Also, since I started down this path, I now get this when I attempt to edit certain site texts:

[tobiaseigen]

Goed opgemerkt en sorry voor de vertraging met reageren! Plaats de volgende keer een Bug onderwerp om er sneller aandacht op te vestigen!

Ik kan dit hier op meta en op mijn persoonlijke site repliceren met behulp van de URL in je screenshot.

/admin/customize/site_texts?q=confirm%20old

[Moin]

@tobiaseigen

/admin/customize/site_texts?q=confirm%20old

I can’t remember that the link ever worked without a locale parameter

/admin/customize/site_texts?q=confirm%20old&locale=en works fine for me.

And I think the fact that you cannot customize the “confirm old email” text is intended. It’s an email only send to staff

@codinghorror

However

the hacker edited the staff old email confirmation template, so that it included the “yes, validate this old email change” URL and then once this was sent to the old email address and clicked, the hacker suddenly had permission to change the old email address to a new one he controls

Bear in mind this is a very sophisticated, in-depth attack, and it could have been stopped many levels above with practices that are already strongly recommended, just read through the lightbulb callouts above.

Still, we believe strongly in being safe by default at Discourse, and we think there is more we can do after closely analyzing this story. As a result, we just implemented a change such that nobody, not even an admin, can modify that particular email template. We believe it is a rare case, but worth addressing, because:

• this particular email template is only ever sent to staff on email change, as both the old and new email addresses must be confirmed. For a regular user only the new email address needs to be confirmed. So changing this template for cosmetic design reasons would only be seen by staff, never by regular users, and is thus unimportant.
• the risk of allowing admins to change this template is too high, as illustrated by the above REAL WORLD story which actually happened, and was the critical step that allowed the attacker access to the complete Discourse database.

[tobiaseigen]

So is this a UX bug too? It shouldn’t be possible to land on a cryptic “Access Denied” page when searching for site texts and then editing them.

[RGJ (Richard - Communiteq)]

It looks like the custom message is not getting through to the user interface?

[Moin]

@Moin

It’s an email only send to staff

It was brought to my attention that since Codinghorror’s post, the require change email confirmation setting has been added. This means the message can now be sent to more than just staff.

The original reason for blocking edits to this template was valid at the time, but today the protection it offers is different. An attacker who knows an admin password can simply:

1. Use the password to set up two-factor authentication for that account.
2. Create a new account.
3. Use the 2FA code to grant the new account admin rights.

From there, they can send the backup to their own email address without needing an admin to click a link to confirm an address change.

So the question is: does blocking edits to this template still make sense? It is now sent to regular users and it does no longer protect the download of a backup.

Also, Data Explorer is now always installed and can be used to access the database.