Erro de Acesso Negado ao tentar personalizar alguns textos do site

[jordan-violet]

Além disso, como comecei por este caminho, agora recebo isto quando tento editar certos textos do site:

[tobiaseigen]

Consigo replicar isso. É este URL que não funciona:

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

[Moin]

@tobiaseigen

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

Não me lembro de o link ter funcionado sem um parâmetro de local

/admin/customize/site_texts?q=confirm%20old&locale=en funciona bem para mim.

E acho que o fato de você não poder personalizar o texto de “confirmar e-mail antigo” é intencional. É um e-mail enviado apenas para a equipe.

@codinghorror

No entanto

o hacker editou o modelo de confirmação de e-mail antigo da equipe, de modo que incluía o URL “sim, valide esta alteração de e-mail antigo” e, em seguida, quando isso foi enviado para o endereço de e-mail antigo e clicado, o hacker de repente teve permissão para alterar o endereço de e-mail antigo para um novo que ele controla

Tenha em mente que este é um ataque muito sofisticado e aprofundado, e poderia ter sido interrompido em muitos níveis acima com práticas que já são fortemente recomendadas, basta ler as chamadas de atenção acima.

Ainda assim, acreditamos firmemente em ser seguros por padrão no Discourse, e achamos que há mais que podemos fazer após analisar cuidadosamente esta história. Como resultado, nós acabamos de implementar uma alteração de modo que ninguém, nem mesmo um administrador, pode modificar esse modelo de e-mail específico. Acreditamos que é um caso raro, mas que vale a pena abordar, porque:

• este modelo de e-mail específico é sempre enviado apenas para a equipe na alteração de e-mail, pois tanto o endereço de e-mail antigo quanto o novo devem ser confirmados. Para um usuário regular, apenas o endereço de e-mail novo precisa ser confirmado. Portanto, alterar este modelo por motivos de design cosmético só seria visto pela equipe, nunca por usuários regulares, e é, portanto, sem importância.
• o risco de permitir que os administradores alterem este modelo é muito alto, como ilustrado pela história REAL do mundo acima que realmente aconteceu, e foi o passo crítico que permitiu ao atacante acesso ao banco de dados completo do Discourse.

[tobiaseigen]

Isso também é um bug de UX? Não deveria ser possível chegar a uma página críptica de "Acesso Negado" ao pesquisar textos do site e depois editá-los.

[RGJ (Richard - Communiteq)]

Parece que a mensagem personalizada não está chegando à interface do usuário?

[Moin]

@Moin

É um e-mail enviado apenas para a equipe

Chegou ao meu conhecimento que, desde a postagem de Codinghorror, a configuração require change email confirmation (exigir confirmação de alteração de e-mail) foi adicionada. Isso significa que a mensagem agora pode ser enviada para mais pessoas do que apenas a equipe.

A razão original para bloquear edições neste modelo era válida na época, mas hoje a proteção que ele oferece é diferente. Um invasor que conhece a senha de um administrador pode simplesmente:

1. Usar a senha para configurar a autenticação de dois fatores para essa conta.
2. Criar uma nova conta.
3. Usar o código 2FA para conceder direitos de administrador à nova conta.

A partir daí, eles podem enviar o backup para seu próprio endereço de e-mail sem precisar que um administrador clique em um link para confirmar uma alteração de endereço.

Portanto, a pergunta é: bloquear edições neste modelo ainda faz sentido? Ele agora é enviado para usuários regulares e não protege mais o download de um backup.

Além disso, o Data Explorer agora está sempre instalado e pode ser usado para acessar o banco de dados.