Impedindo ataques de enumeração de nome de usuário com o Spring Security

O registro do usuário precisa de um nome de usuário exclusivo e o endereço de email geralmente é escolhido por simplicidade. Agora, se escolhermos um email que já existe, o aplicativo deverá nos informar:

Juntamente com o fato de não ser difícil encontrar uma lista de emails, isso pode levar a um ataque de enumeração de nome de usuário para descobrir nomes de usuário válidos no aplicativo.

Da mesma forma, quando tentamos fazer login em um aplicativo, é necessário fornecer nome de usuário e senha. Agora, se um nome de usuário que fornecemos não existir, o aplicativo poderá retornar essas informações para nós:

Isso, como antes, é simples o suficiente para aproveitar um ataque de enumeração de nome de usuário.

A redefinição de senha geralmente é implementada para enviar um link de redefinição de senha para o e-mail de um usuário. Agora, novamente, será necessário fornecer um nome de usuário ou email:

Se esse nome de usuário ou email não existir no aplicativo, ele será informado como tal, levando a uma vulnerabilidade semelhante à que vimos anteriormente.

Primeiro, devemos excluir todas as possibilidades de fornecer inadvertidamente mais informações do que o necessário. Isso seria difícil no registro, mas bastante simples no login e redefinir as páginas de senha.

Por exemplo, podemos facilmente tornar a mensagem para a página de login abstrata:

Podemos fazer ajustes semelhantes à mensagem da página de redefinição de senha.

Embora ajustar as mensagens funcione bem em algumas páginas, há páginas como o registro em que é complicado fazer isso. Nesses casos, podemos usar outra ferramenta chamada CAPTCHA.

Agora, neste ponto, vale a pena observar que qualquer ataque de enumeração provavelmente é robótico devido a um vasto número de possibilidades para percorrer. Portanto,detecting a human or robotic presence can help us prevent an attack. CAPTCHA serve como uma maneira popular de conseguir isso.

Existem várias maneiras possíveis de implementar ou integrar serviços CAPTCHA em um aplicativo da web. Um desses serviços éreCAPTCHA by Google, which can be easily integrated on the registration page.

Embora o CAPTCHA atenda bem ao objetivo, ele adiciona latência e, mais importante, inconvenientes aos usuários legítimos. Isso é mais relevante para páginas usadas com frequência, como login.

One technique that can help prevent robotic attacks on frequently used pages like login is rate limiting. A limitação de taxa refere-se à prevenção de tentativas sucessivas de um recurso após um determinado limite.

Por exemplo, podemos bloquear solicitações de um IP específico por um dia após três tentativas falhas no login:

A Spring Security torna isso particularmente conveniente.

Começamos definindo ouvintes paraAuthenticationFailureBadCredentialsEvent and AuthenticationSuccessEvent.. Esses ouvintes chamam um serviço que registra o número de tentativas malsucedidas de um determinado IP. Depois que um limite definido é violado, as solicitações subsequentes são bloqueadas emUserDetailsService.

A detailed discussion on this approach is available in another tutorial.

Além disso, podemos capturar a localização por país de um usuário durante o registro. Podemos usar isso para verificar uma tentativa de login originada em um local diferente. Se detectarmos um local incomum, ações adequadas podem ser tomadas:

Mais uma vez, o Spring Security, por meio de seus pontos de extensão, torna possível conectar um serviço de verificação de localização personalizado noAuthenticationProvider. A particular flavor of this has been described in detail in a previous tutorial.

Por fim, devemos observar que a autenticação baseada em senha geralmente é a primeira e, na maioria dos casos, a única etapa necessária. Masit’s not uncommon for applications to adopt multi-factor authentication mechanisms for better security. Isto é especialmente verdade para aplicativos confidenciais como banco on-line.

Existem muitos fatores possíveis quando se trata de autenticação multifatorial:

O Spring Security é bastante conveniente aqui também, pois nos permite conectar umAuthenticationProvider. personalizado. O aplicativo Google Authenticator é uma escolha popular para implementar o fator de posse adicional. Isso permite que os usuários gerem um token efêmero no aplicativo em seu smartphone e o usem para autenticação em qualquer aplicativo. Obviamente, isso requer a configuração prévia do usuário no aplicativo, durante o registro ou posteriormente.

Integrating Google Authenticator in a Spring security application has been well covered in a previous tutorial.

Mais importante,a solution like multi-factor authentication is only suitable if the application needs it. Portanto, não devemos usá-lo principalmente para impedir ataques de enumeração.

Ao processar uma solicitação como um login, verificar se o nome de usuário existe é geralmente a primeira coisa que fazemos. Se um nome de usuário não existir, a solicitação retornará imediatamente com um erro. Pelo contrário, uma solicitação com um nome de usuário válido envolveria muitas etapas adicionais, como correspondência de senha e verificação de função. Naturalmente, o tempo para responder a ambos os casos pode variar.

Agora, mesmo que abstraiamos a mensagem de erro para ocultar o fato de um nome de usuário ser válido ou não, uma diferença significativa no tempo de processamento pode avisar um invasor.

Uma solução possível para esse problema pode ser adicionar um atraso forçado para descartar a diferença nos tempos de processamento. No entanto, como esse não é um problema que possa ocorrer com certeza, devemos empregar essa solução apenas se necessário.