Accesso negato errore durante la personalizzazione di alcuni testi del sito

[jordan-violet]

Inoltre, da quando ho intrapreso questa strada, ora ricevo questo quando tento di modificare determinati testi del sito:

[tobiaseigen]

Sono in grado di replicarlo. È questo URL che non funziona:

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

[Moin]

@tobiaseigen

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

Non ricordo che il link abbia mai funzionato senza un parametro di locale

/admin/customize/site_texts?q=confirm%20old&locale=en funziona bene per me.

E penso che il fatto che tu non possa personalizzare il testo “conferma vecchia email” sia intenzionale. È un’email inviata solo allo staff.

@codinghorror

Tuttavia

l’hacker ha modificato il template della vecchia email di conferma dello staff, in modo che includesse l’URL “sì, valida questa vecchia modifica dell’email” e una volta che questo è stato inviato alla vecchia email e cliccato, l’hacker ha improvvisamente avuto il permesso di cambiare la vecchia email in una nuova che controlla

Tieni presente che si tratta di un attacco molto sofisticato e approfondito, e avrebbe potuto essere fermato a molti livelli superiori con pratiche già fortemente raccomandate, basta leggere i riquadri con la lampadina sopra.

Tuttavia, crediamo fermamente nell’essere sicuri per impostazione predefinita in Discourse, e pensiamo che ci sia altro che possiamo fare dopo aver analizzato attentamente questa storia. Di conseguenza, abbiamo appena implementato una modifica tale che nessuno, nemmeno un amministratore, può modificare quel particolare template di email. Crediamo che sia un caso raro, ma vale la pena affrontarlo, perché:

• questo particolare template di email viene inviato solo allo staff in caso di cambio email, poiché sia l’indirizzo email vecchio che quello nuovo devono essere confermati. Per un utente normale solo il nuovo indirizzo email deve essere confermato. Quindi modificare questo template per motivi di design estetico sarebbe visto solo dallo staff, mai dagli utenti normali, ed è quindi irrilevante.
• il rischio di consentire agli amministratori di modificare questo template è troppo alto, come illustrato dalla storia REALE di cui sopra che è effettivamente accaduta, ed è stato il passaggio critico che ha permesso all’attaccante di accedere al database completo di Discourse.

[tobiaseigen]

Quindi questo è anche un bug di UX? Non dovrebbe essere possibile finire su una pagina criptica “Accesso negato” quando si cercano testi del sito e poi li si modifica.

[RGJ (Richard - Communiteq)]

Sembra che il messaggio personalizzato non venga visualizzato nell’interfaccia utente?

[Moin]

@Moin

È un’email inviata solo allo staff

Mi è stato segnalato che, a partire dal post di Codinghorror, è stata aggiunta l’impostazione richiedi conferma email di modifica. Ciò significa che il messaggio ora può essere inviato anche a utenti non staff.

Il motivo originale per bloccare le modifiche a questo modello era valido all’epoca, ma oggi la protezione che offre è diversa. Un aggressore che conosce la password di un amministratore può semplicemente:

1. Usare la password per configurare l’autenticazione a due fattori per quell’account.
2. Creare un nuovo account.
3. Usare il codice 2FA per concedere all’account nuovo i diritti di amministratore.

Da lì, possono inviare il backup al proprio indirizzo email senza bisogno che un amministratore clicchi su un link per confermare una modifica dell’indirizzo.

Quindi la domanda è: bloccare le modifiche a questo modello ha ancora senso? Ora viene inviato agli utenti normali e non protegge più il download di un backup.

Inoltre, Data Explorer è ora sempre installato e può essere utilizzato per accedere al database.