Vulnerabilidade de enumeração de email na caixa de diálogo "Redefinir senha"

OWASP Vulnerability ID: WSTG-IDNT-04

Passos de Reprodução:

  1. Tente usar um e-mail inválido no diálogo “esqueci meu e-mail”:
  2. Tente usar um e-mail válido no diálogo “esqueci meu e-mail”:

Descrição da Vulnerabilidade (da OWASP):

  • É possível coletar um conjunto de nomes de usuário válidos interagindo com o mecanismo de autenticação da aplicação. Este teste será útil para testes de força bruta, nos quais o testador verifica se, dado um nome de usuário válido, é possível encontrar a senha correspondente.

  • Frequentemente, aplicações web revelam quando um nome de usuário existe no sistema, seja como consequência de má configuração ou como uma decisão de design. Por exemplo, às vezes, quando enviamos credenciais incorretas, recebemos uma mensagem que afirma que o nome de usuário está presente no sistema ou que a senha fornecida está errada. As informações obtidas podem ser usadas por um invasor para obter uma lista de usuários no sistema. Essas informações podem ser usadas para atacar a aplicação web, por exemplo, por meio de um ataque de força bruta ou de nome de usuário e senha padrão.

Correção Sugerida:

  1. O diálogo “esqueci meu e-mail” deve se comportar da mesma forma, independentemente de o e-mail ser válido ou inválido.

Nós temos a configuração de administrador hide email address taken que altera o comportamento dessa tela:

Talvez seria bom tê-la como padrão? :thinking:

9 curtidas

Habilitar Admin - Configurações - Login - ocultar e-mail já existente

ocultar e-mail já existente

Não informe aos usuários que uma conta existe com um determinado endereço de e-mail durante o cadastro ou durante o fluxo de “esqueci minha senha”. Exija o e-mail completo para solicitações de “esqueci minha senha”.

Veja também Different password reset for wrong username/email (2014 :wink: )

Editar @JammyDodger foi 40 segundos mais rápido

7 curtidas

Lendo um pouco, isso já aconteceu algumas vezes antes. Acho que um dos outros pontos importantes é que temos limite de taxa ao tentar fazer login:

3 curtidas

Obrigado a ambos. Deparei-me com este bug organicamente em meta.discourse.org e não sabia dessa configuração, mas é bom saber que a correção já está codificada e o patch deve ser muito simples. Para satisfazer as melhores práticas da OWASP, essa configuração deve estar sempre ativada. Não sei por que qualquer administrador gostaria de ter isso desativado, pois fazê-lo representa uma vulnerabilidade de segurança e privacidade totalmente desnecessária que viola explicitamente os padrões de melhores práticas da indústria. Se houver algum motivo para preservar essa opção para instalações legadas que não consigo entender, um aviso deve ser adicionado para indicar que a configuração atual viola as melhores práticas padrão da indústria e recomendar a configuração compatível em vez disso.

2 curtidas

Obrigado por linkar este tópico. @awesomerobot tem direito à sua opinião, mas também está desafiando descaradamente as melhores práticas padrão da indústria e insistindo que um bug bem conhecido, frequentemente relatado e explicitamente codificado é de alguma forma “não um bug”, e eu não acho a opinião deles muito convincente em comparação com as melhores práticas padrão publicadas da indústria.

No mínimo, o valor padrão deve refletir a configuração mais segura, e deve haver alguma indicação para dizer aos administradores novatos que desabilitar esta opção constitui uma vulnerabilidade de segurança e privacidade deliberada e desnecessária em seu fórum. Um link para a entrada da OWASP ou algo assim.

Alguém pode me dar uma pista sobre o cenário em que pode ser preferível ter esta opção desabilitada? Eu genuinamente não sei por que isso é uma questão controversa e gostaria de saber se estou perdendo algum caso de uso que anule o modelo de segurança opt-in implementado com esta configuração. Se tal cenário não puder ser sugerido, então esta configuração deve estar sempre habilitada e, portanto, não deveria ser uma configuração.

1 curtida

Eu acho que, atualmente, tudo está funcionando como esperado, então não podemos realmente classificar isso como um Bug. No entanto, reavaliamos rotineiramente nossos padrões e você fez alguns pontos interessantes que valem a pena considerar.

Vou mover isso para UX para que a conversa possa continuar lá. :+1:

11 curtidas

Simplesmente… as pessoas são ruins em lembrar qual endereço de e-mail usaram para criar uma conta e entrarão em contato com os administradores para solucionar problemas.

Isso é semelhante a exigir segundo fator ou comprimento mínimo da senha — acho que a recomendação geral é sempre exigir um segundo fator, e as recomendações de comprimento mínimo de senha agora parecem ser maiores do que nosso padrão atual para usuários comuns… mas também há uma lacuna entre as recomendações de segurança e as habilidades computacionais médias.

Não sou fortemente contra mudar os padrões, mas vale a pena notar que eles podem impactar a usabilidade.

10 curtidas

Isso, para mim, parece que as configurações padrão do Discourse deveriam seguir as melhores práticas - como quase todos os outros sites fazem.

Parece que tenho a configuração apropriada definida na minha instância:

Se uma conta corresponder a x@example.com, você deverá receber um e-mail com instruções sobre como redefinir sua senha em breve.

3 curtidas

Gosto desse feedback, mas preferiria se fosse respaldado com um pouco mais de dados:

O que os seguintes sites fazem?

  • Facebook
  • Twitter
  • Amazon
  • Reddit
  • Yahoo
3 curtidas

Obrigado a todos pelas suas valiosas contribuições e perspectivas sobre este bug. Para mim, isto é muito simples e nada complicado: existe um bug bem conhecido presente no Discourse que tem sido repetidamente levantado por administradores e profissionais de segurança como eu, e está a ser tratado como uma funcionalidade em vez de uma vulnerabilidade de segurança: NIST: CWE-200: Exposição de Informações Sensíveis a um Ator Não Autorizado.

Justificar esta configuração padrão insegura que viola as melhores práticas padrão da indústria, citando uma situação hipotética em que um administrador de fórum é inundado com perguntas de utilizadores sobre quais e-mails usaram para se inscrever, não faz sentido, pois usar a página “esqueci a minha palavra-passe” não necessitaria desta interação do administrador, independentemente da configuração desta definição: se a configuração mais segura e em conformidade com os padrões estiver ativada, o utilizador simplesmente verificaria o(s) seu(s) e-mail(s) no diálogo “esqueci o meu e-mail” e veria se esse endereço recebeu um e-mail de redefinição de palavra-passe, exatamente como explicado pelo diálogo, e como é comum em todas as aplicações web modernas, que respeitam a privacidade e estão em conformidade com os padrões. Além disso, justificar esta violação com base na premissa de que outros sites também podem estar a violar as melhores práticas não é um argumento lógico ou convincente de uma perspetiva de segurança e proteção de dados. Luto para entender por que estamos a dar aos administradores a “funcionalidade” de tornar a sua instalação Discourse marginalmente menos segura e em conformidade com os padrões, sem um benefício claro.

No entanto, fiz o trabalho que você prescreveu, @sam:
‌1. Google: não permite a enumeração de utilizadores.
2. YouTube: não permite a enumeração de utilizadores (porque usa o login do Google, e o Google não permite a enumeração de utilizadores).
3. Facebook: permite oficialmente a enumeração de utilizadores através da sua página “encontrar uma conta”/“esqueci a minha palavra-passe” apenas se o utilizador tiver marcado deliberadamente o seu e-mail/número de telefone como público, e ainda assim vazou famosamente dados de 500 milhões de utilizadores através deste tipo de vulnerabilidade, e pagou milhares de dólares a auditores de segurança que descobriram que a sua limitação de taxa e as regras de “apenas se explicitamente marcado como público” não estavam a ser seguidas internamente.
4. Instagram: permite a enumeração de utilizadores (e foi queimado por isso). Este é um hack diferente do que mencionei para o Facebook.
5. X (por favor, seja respeitoso sobre dead-naming neste fórum): permite a enumeração de utilizadores através da sua página de esqueci a palavra-passe, mas implementa limitação de taxa e alguns outros obstáculos facilmente contornáveis e ainda assim comprometeu famosamente os números de telefone dos seus utilizadores através de um bug na sua implementação de limitação de taxa e proteções de privacidade de dados.
6. Baidu: permite a enumeração de utilizadores na página de esqueci o e-mail, e implementa captcha (e talvez limitação de taxa? O meu chinês é mau). Curiosamente, o processo de recuperação requer a abertura de um recurso com a equipa de administração, em vez de um simples e-mail de recuperação. Muito típico do controlo central do PCC.
7. Wikipedia: não permite a enumeração de utilizadores.
8. Yahoo: Permite a enumeração de utilizadores através da sua página de esqueci a palavra-passe, mas implementa limitação de taxa e captcha. Não consegui encontrar exemplos de o Yahoo ter sido apanhado em controvérsias ou ter pago hackers que exploram este bug, mas é realmente difícil pesquisar por Yahoo em qualquer motor de busca por razões óbvias.
9. Yandex: permite a enumeração de utilizadores na página de login, implementa captcha e pergunta de desafio na página de esqueci o e-mail.
10. Whatsapp: não permite a enumeração de utilizadores. O login no PC é feito através de credenciais móveis. As credenciais móveis estão vinculadas ao seu número de telefone. Não há botão de logout, nem página de login/esqueci o meu e-mail.
11. XVideos: não permite a enumeração de utilizadores.
12. PornHub: não permite a enumeração de utilizadores.
13. Amazon (site de e-commerce): permite a enumeração de utilizadores através da sua página de esqueci a palavra-passe, em violação direta das suas próprias recomendações de melhores práticas para o produto de pools de utilizadores do Amazon Web Services. Não consegui encontrar exemplos de a Amazon ter sido apanhada em controvérsias ou ter pago hackers que exploram este bug, mas é realmente difícil pesquisar por Amazon em qualquer motor de busca por razões óbvias.
14. Xnxx: não permite a enumeração de utilizadores. O site principal não tem realmente uma página de login, e o site ‘gold’ não permite a enumeração de utilizadores. Encontrei uma página de login desativada na versão móvel do site regular, e simplesmente não tem funcionalidade de “esqueci o meu e-mail” (e também está aparentemente desativada, em favor do seu site ‘gold’).
15. Tik Tok: não permite a enumeração de utilizadores. Impõe MFA na página de esqueci a palavra-passe.
(21. Reddit: Não permite a enumeração de utilizadores. Eles estão em conformidade com as melhores práticas padrão da indústria.)

Dos 15 principais sites dessa lista, 8/15 NÃO permitem a enumeração de utilizadores (ou 9/16 se incluirmos o Reddit, e argumentavelmente adicionarmos 0,5 para o Facebook, já que ele só permite a enumeração de informações que o utilizador aprovou deliberadamente tornar públicas), e pelo menos 3/7 dos sites dessa lista que PERMITEM a enumeração de utilizadores enfrentaram eventos de segurança críticos como resultado dessa decisão.

2 curtidas

Isso é um tanto desonesto, pois o principal produto do Google (gmail) permite a enumeração.

É, de resto, trivial testar a existência de contas em provedores de identidade de e-mail, então não há muito sentido em incluí-los na lista.

Nenhuma das outras plataformas nessa lista é (potencialmente) software auto-hospedado.

Não há uma Plataforma Central do Discourse - os administradores do site são livres para escolher por si mesmos.

Dito isso, concordo em dar um empurrão aos administradores do site para que escolham boas configurações por padrão.

Talvez um controle que os administradores possam girar (hesito em sugerir adicioná-lo ao assistente) para apertar facilmente configurações como essa.

4 curtidas

Isso não se aplica a qualquer site com uma página de cadastro, não apenas a provedores de serviços de e-mail? Entendo seu ponto sobre como as páginas de cadastro são um vetor potencial para vulnerabilidades semelhantes de privacidade e dados e, portanto, devem ser protegidas, mas essa é uma parte diferente do fluxo de autenticação do usuário do que estamos discutindo neste tópico. Neste tópico, estamos analisando especificamente vazamentos do diálogo “esqueci minha senha”. Não me entenda mal: ambos são absolutamente importantes, exigem atenção cuidadosa e requerem mitigações para prevenir vulnerabilidades de privacidade e dados. Geralmente, para formulários de cadastro, você exige um captcha, e para endpoints de “esqueci minha senha”, você quer ter a mesma resposta, independentemente de o e-mail ser válido ou inválido. Muitos sites também protegem o endpoint “esqueci minha senha” com um captcha. Ambos os endpoints devem ter limite de taxa.

Certamente não estava tentando ser desonesto. Não acho que tudo bem ser não-conforme porque outros sites também são não-conformes seja uma conclusão logicamente sólida de qualquer maneira, eu estava apenas cumprindo o pedido de Sam e para aliviar quaisquer preocupações que ele pudesse ter, fornecendo a “prova” que ele buscava usando o link que ele forneceu.

O software MediaWiki é usado por dezenas de milhares de sites e milhares de empresas e organizações. Ele alimenta a Wikipédia e é um software amplamente auto-hospedado.

Eu certamente encorajo a liberdade do administrador e não gosto de dificultar a vida de administradores ou usuários, mas não acho que os “prós” dessa configuração superem os “contras” em qualquer cenário, e não há caso em que um administrador realmente QUEIRA esse “recurso”. Assim como não permitimos que um administrador imponha um comprimento máximo de senha, não deveríamos permitir que eles degradem desnecessariamente a segurança de seu fórum, permitindo essa vulnerabilidade de enumeração no diálogo “esqueci minha senha”. Acho que deveríamos simplesmente remover a opção inteiramente e forçar todos a seguir o caminho compatível com os padrões. Honestamente, não acho que a maioria dos administradores notaria ou se importaria, mas tornaria um endpoint voltado para a internet pública um pouco mais seguro em todas as instalações do Discourse. Se precisarmos incluir a configuração, então ela deve estar na posição mais segura por padrão, e a posição menos segura deve ser claramente demarcada para que administradores novatos entendam por que não é recomendada. Acho que simplesmente refatorar essa configuração para fora da existência é a melhor opção. Ficarei feliz em enviar um PR para isso.

1 curtida

Não acho que você possa analisar nenhum dos dois isoladamente. No processo de inscrição do Discourse, há uma mensagem “E-mail já em uso” e é difícil ver como fazer isso de forma diferente. Enquanto isso existir, é difícil ver qual é o grande problema com a mensagem “Encontramos uma conta que corresponde” especificamente.

Suponho que faria diferença em um fórum que permite apenas autenticação externa.

Superada a vontade de discordar de você apenas por causa do seu estilo, acho que, no mérito, você está certo na medida em que sua posição é que o padrão deve ser a opção mais segura, pelo menos quando a autenticação externa é usada. Ainda não concordo que não haja lugar para a opção menos segura (meu fórum tem o processo de inscrição padrão do Discourse, então não planejo mudar a opção de redefinição de senha).

A propósito, ri do fato de você ter deixado o leitor adivinhar pelo contexto que XVideos e Xnxx (embora não X) são pornográficos, mas se deu ao trabalho de explicar que a Amazon é um “site de comércio eletrônico”.

1 curtida

Era para distinguir a Amazon.com da AWS. E já que você perguntou: a AWS não permite a enumeração de usuários. :slightly_smiling_face:

Concordo que você deve considerar todas as etapas de um fluxo de autenticação de usuário e como elas funcionam juntas. Isso é extremamente importante e uma das fontes mais comuns de vulnerabilidades de segurança. Se aquele bug semelhante de enumeração de e-mail na página de cadastro que você mencionou não for devidamente mitigado, ele deve ser corrigido, independentemente do resultado deste tópico. Seria um bug na implementação de hide_email_address_taken. A discussão desse potencial bug/lapso provavelmente deveria ocorrer em outro tópico (e provavelmente com uma tag de bug).

1 curtida

Só para notar, com hide email address taken ativado, ele também não exibe essa mensagem na inscrição (ele também altera a mensagem de convite quando um e-mail existente é inserido lá). :+1:

Acho que uma das possíveis complicações para simplesmente inverter o padrão é que ele também tem o ‘require full email for password reset’ integrado, o que pode complicar demais as coisas (embora provavelmente não seja um bloqueador completo).

2 curtidas

Obrigado. Provavelmente mudarei a configuração então. Acho que algo neste tópico me deu a impressão errada.

O que isso significa? Significa que você não pode obter uma redefinição de senha apenas com o nome de usuário?

1 curtida

É esse mesmo. :+1: Com ocultar e-mail já em uso ativado, você precisa inserir o próprio e-mail da conta para redefinir a senha, e não pode usar apenas um nome de usuário.

1 curtida

Sugiro que renomeemos a SiteSetting hide_email_address_taken para prevent_password_recovery_by_username, e então refatoramos o comportamento não conforme para fora do aplicativo para todos os usuários. Isso preservaria a funcionalidade de redefinição de senha sem alterações para todas as instalações, ao mesmo tempo em que abordaria a vulnerabilidade de enumeração de e-mail. Sou um desenvolvedor experiente em RoR + javascript e ficaria feliz em implementar este pull request; dei uma olhada rápida no codebase e posso ver que não seria um PR muito extenso.

Se refatorar essa ‘funcionalidade’ para fora de existência realmente não for uma opção, ainda acho que faz sentido desacoplar esses dois conceitos relacionados em entradas separadas de SiteSetting.

1 curtida
2 curtidas