Os aplicativos da Web são frequentemente alvo de invasores mal-intencionados. Esses aplicativos são acessíveis ao público - ou, pelo menos, suas páginas de login são - e não é difícil para um invasor determinado encontrar sites com falhas de segurança. Os invasores geralmente tentam explorar as vulnerabilidades de segurança da página de login em um aplicativo da Web para causar carga excessiva e, possivelmente, derrubar o site.
Uma dessas vulnerabilidades pode ser encontrada na página de perguntas de segurança que faz parte de muitos fluxos de login. Nesta postagem, analisaremos esse cenário, examinaremos por que ele é um problema e forneceremos orientações sobre como atenuar esse risco de segurança.
A página de login com uma pergunta de segurança em branco
As vulnerabilidades de segurança da página de login são mais comuns do que você imagina. No processo de login de muitos sites e aplicativos, uma proteção de verificação adicional estende a etapa tradicional de nome de usuário/senha para aumentar a segurança. Imagine um fluxo de login em duas etapas. Na primeira etapa, o site solicita uma combinação de nome de usuário e senha. Se você digitar essas credenciais corretamente, a segunda etapa solicitará que você responda a uma pergunta de segurança (que você especificou quando configurou sua conta pela primeira vez).
Essa segunda etapa geralmente é criada a partir de um modelo de exibição de página que insere a pergunta de segurança com base no usuário que concluiu com êxito a primeira etapa. Todo o fluxo de login em duas etapas funciona basicamente assim:
- Alice acessa a página de login em https://www.example.com/login.
- Alice envia uma combinação de nome de usuário e senha.
- O servidor verifica as credenciais enviadas.
- Como as credenciais estavam corretas, o servidor redireciona o navegador para a página de acompanhamento em https://www.example.com/login2, incluindo um token exclusivo no cabeçalho da solicitação para verificar se Alice passou na primeira etapa do fluxo de login.
- O servidor renderiza essa página com base em um modelo, inserindo a pergunta de segurança obtida para Alice, juntamente com a entrada de texto para uma resposta e um botão de envio.
- Alice envia a resposta à sua pergunta de segurança.
- O servidor verifica se Alice respondeu corretamente à pergunta de segurança e, em seguida, faz o login.
Vamos nos concentrar na segunda página do fluxo, em https://www.example.com/login2. Imagine o que aconteceria se você visitasse essa página diretamente em seu navegador, sem passar pela primeira etapa.
Em um cenário, é possível que o servidor verifique se não há um token válido no cabeçalho da solicitação (o que significa que você não passou com êxito na primeira etapa do fluxo de login) e simplesmente o redirecione de volta para https://www.example.com/login para começar de novo.
Entretanto, em outro cenário possível, o servidor ainda renderiza a página com base no modelo. Como não é possível encontrar uma pergunta de segurança correspondente para o usuário (já que não há um token que informe ao servidor qual é o usuário autenticado pela metade), a página resultante pode ter a seguinte aparência:
Você fica com uma página de pergunta de segurança incômoda que não tem... nenhuma pergunta de segurança. Essa é uma página sem sentido.
Inútil, sim. Mas inofensivo? Não tenha tanta certeza.
As implicações de segurança
Continuando com esse cenário, o que aconteceria quando você (ou uma pessoa mais mal-intencionada do que você) enviasse uma resposta a essa "pergunta de segurança"? O servidor dedicará ciclos de CPU para avaliar sua resposta. Ele processará a entrada de texto, procurará o token exclusivo no cabeçalho da solicitação e possivelmente até executará uma consulta ao banco de dados na tentativa de validar sua resposta.
Uma página de login com uma pergunta de segurança em branco pode parecer insignificante(o que há de errado com alguns ciclos de CPU desperdiçados aqui e ali?), mas pode levar a sérios problemas de segurança.
- Desperdício de recursos de processamento de back-end: O processamento de envios de formulários inúteis consome recursos de rede e de computação e, possivelmente, também recursos de banco de dados.
- Possibilidade de ataques de negação de serviço (DoS): Um invasor pode configurar um botnet para enviar envios de formulários repetidamente, sobrecarregando o sistema.
- Maior vulnerabilidade: Um ataque de DoS bem-sucedido pode derrubar todo o seu sistema.
Se os invasores puderem explorar esse ponto fraco para desperdiçar o poder de processamento de um servidor, eles poderão interromper os serviços para usuários legítimos e expor o sistema a outros ataques.
Afinal, não é tão inofensivo assim.
Vamos ver como lidar com vulnerabilidades como essas para manter a segurança e a confiabilidade de seus aplicativos.
Como se defender
Para esse cenário específico, o servidor que lida com o ponto de extremidade login2 deve verificar a existência de um token válido no cabeçalho da solicitação. Sem um token adequado, nenhum processamento adicional deve ocorrer, e o usuário deve ser redirecionado para a primeira etapa do fluxo de login. Dessa forma, você minimiza os recursos usados para lidar com a solicitação de forma graciosa, da mesma forma que faz com um 404 ou um 401.
No entanto, esse cenário destaca uma preocupação de segurança mais geral que você deve observar: solicitações repetidas que sobrecarregam seu servidor com uma carga excessiva. Certamente, a exploração de uma página de login sem sentido com uma pergunta de segurança em branco pode sobrecarregar seu servidor mais rapidamente devido à quantidade de recursos de processamento usados. Mas um botnet também pode atingir sua página de login de nome de usuário/senha perfeitamente normal com solicitações excessivas.
Para proteger seus aplicativos da Web contra esses tipos de ataques, implemente as seguintes medidas:
- Use um firewall de aplicativo da Web (WAF): Um WAF pode fornecer proteção contra DoS e detectar e bloquear bots mal-intencionados, reduzindo o risco de ataques automatizados. O marketplace de aplicativos da Linode inclui o Haltdos Community WAF, que pode ajudá-lo com isso.
- Implemente a limitação de taxa: Limite o número de solicitações que um único endereço IP pode fazer em um determinado período de tempo. Com a limitação de taxa, você evitará que os invasores (e bots) inundem seu sistema com solicitações.
- Habilite o monitoramento e os alertas: As ferramentas de monitoramento contínuo podem estar atentas a padrões de solicitação suspeitos, alertando-o em tempo real sobre possíveis ataques. Quando você é notificado imediatamente, pode responder e atenuar um problema rapidamente.
Conclusão
Examinamos o caso de uma página de login com uma pergunta de segurança em branco. À primeira vista, parece uma página estranha de caso extremo que, em última análise, é inútil. Mas os invasores podem explorar vulnerabilidades como essa para desperdiçar seus recursos e, possivelmente, derrubar seu sistema. A página de pergunta de segurança é apenas um exemplo dessa vulnerabilidade.
Se você projetar seus aplicativos com a segurança em mente e adotar práticas de codificação seguras, terá um bom começo. No entanto, seus aplicativos também precisam de medidas de segurança implementadas no nível do sistema e da infraestrutura, como o uso de um WAF, limitação de taxa, monitoramento contínuo e alertas. Com as medidas de segurança adequadas em vigor, você pode reduzir significativamente o risco de ser alvo de tais ataques.
Para obter mais orientações e dicas sobre como proteger seus aplicativos, consulte os documentos da Linode, com sua rica biblioteca de guias relacionados à segurança. Lá, você encontrará recursos úteis para orientá-lo sobre como proteger seus sistemas e seus usuários.
Comentários