As aplicações Web são frequentemente visadas por atacantes maliciosos. Estas aplicações estão acessíveis ao público - ou, pelo menos, as suas páginas de início de sessão estão - e não é difícil para um atacante determinado encontrar sites com falhas de segurança. Os atacantes tentam muitas vezes explorar as vulnerabilidades de segurança da página de início de sessão numa aplicação Web para causar uma carga excessiva e, potencialmente, deitar o site abaixo.
Uma dessas vulnerabilidades pode ser encontrada na página de perguntas de segurança que faz parte de muitos fluxos de login. Nesta publicação, vamos analisar este cenário, examinar porque é que é um problema e fornecer orientações sobre como mitigar esse risco de segurança.
A página de login com uma pergunta de segurança em branco
As vulnerabilidades de segurança das páginas de início de sessão são mais comuns do que se possa pensar. No processo de início de sessão de muitos sítios Web e aplicações, uma salvaguarda de verificação adicional alarga o passo tradicional do nome de utilizador/palavra-passe para aumentar a segurança. Imagine um fluxo de início de sessão em dois passos. Na primeira etapa, o site pede-lhe uma combinação de nome de utilizador e palavra-passe. Se introduzir estas credenciais corretamente, o segundo passo pede-lhe que responda a uma pergunta de segurança (que especificou quando configurou a sua conta pela primeira vez).
Esta segunda etapa é normalmente criada a partir de um modelo de visualização de página que insere a pergunta de segurança com base no utilizador que concluiu com êxito a primeira etapa. Todo o fluxo de login em duas etapas funciona basicamente assim:
- Alice visita a página de início de sessão em https://www.example.com/login.
- Alice submete uma combinação de nome de utilizador e palavra-passe.
- O servidor verifica as credenciais apresentadas.
- Como as credenciais estavam corretas, o servidor redirecciona o browser para a página de seguimento em https://www.example.com/login2, incluindo um token único no cabeçalho do pedido para verificar se Alice passou o primeiro passo do fluxo de início de sessão.
- O servidor processa esta página com base num 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 à sua pergunta de segurança e, em seguida, inicia a sessão.
Vamos concentrar-nos na segunda página do fluxo, em https://www.example.com/login2. Imagine o que aconteceria se visitasse essa página diretamente no seu browser, sem passar pelo primeiro passo.
Num cenário, é possível que o servidor verifique se não existe um token válido no cabeçalho do pedido (o que significa que o utilizador não passou com êxito o primeiro passo do fluxo de início de sessão) e simplesmente redirecciona o utilizador para https://www.example.com/login para começar de novo.
No entanto, em outro cenário possível, o servidor ainda renderiza a página com base no modelo. Incapaz de encontrar uma pergunta de segurança correspondente para o utilizador (uma vez que não existe um token que indique ao servidor qual é o utilizador meio-autenticado), a página resultante pode ter o seguinte aspeto:
Fica-se com uma página de perguntas de segurança estranha que não tem... nenhuma pergunta de segurança. É uma página sem sentido.
Inútil, sim. Mas inofensivo? Não tenhas tanta certeza.
As implicações para a segurança
Continuando com este cenário, o que aconteceria quando você (ou uma pessoa mais maliciosa do que você) enviasse uma resposta a esta "pergunta de segurança"? O servidor dedicará ciclos de CPU para avaliar a sua resposta. Processará a entrada de texto, procurará o token único no cabeçalho do pedido e possivelmente até executará uma consulta à base de dados numa tentativa de validar a sua resposta.
Uma página de início de sessão 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 submissões de formulários inúteis consome recursos de rede e de computação - e possivelmente também recursos de base de dados.
- Potencial para ataques de negação de serviço (DoS): Um atacante pode configurar um botnet para enviar formulários repetidamente, sobrecarregando o sistema.
- Maior vulnerabilidade: Um ataque DoS bem sucedido pode deitar abaixo todo o seu sistema.
Se os atacantes conseguirem explorar esta fraqueza para desperdiçar o poder de processamento de um servidor, podem potencialmente interromper os serviços para utilizadores legítimos e expor o sistema a outros ataques.
Afinal, não é assim tão inofensivo.
Vejamos como resolver vulnerabilidades como estas para manter a segurança e a fiabilidade das suas aplicações.
Como se defender
Para este 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 do pedido. Sem um token adequado, não deve ser efectuado qualquer processamento adicional e o utilizador deve ser redireccionado para o primeiro passo do fluxo de início de sessão. Desta forma, minimiza os recursos utilizados para tratar o pedido de forma graciosa, tal como acontece com um 404 ou um 401.
No entanto, este cenário realça uma preocupação de segurança mais geral a que deve estar atento: pedidos repetidos que sobrecarregam o seu servidor com uma carga excessiva. É certo que a exploração de uma página de início de sessão sem sentido com uma pergunta de segurança em branco pode sobrecarregar o seu servidor mais rapidamente devido à quantidade de recursos de processamento utilizados. Mas um botnet também pode atingir a sua página de início de sessão de nome de utilizador/palavra-passe perfeitamente normal com pedidos excessivos.
Para proteger as suas aplicações Web contra este tipo de ataques, implemente as seguintes medidas:
- Utilizar uma firewall de aplicação web (WAF): Um WAF pode fornecer proteção DoS e detetar e bloquear bots maliciosos, reduzindo o risco de ataques automatizados. O mercado de aplicativos da Linode inclui o Haltdos Community WAF, que pode ajudá-lo com isso.
- Implementar limitação de taxa: Limite o número de pedidos que um único endereço IP pode fazer num determinado período de tempo. Com a limitação da taxa, evitará que os atacantes (e bots) inundem o seu sistema com pedidos.
- Permitir a monitorização e a emissão de alertas: As ferramentas de monitorização contínua podem estar atentas a padrões de pedidos suspeitos, alertando-o em tempo real para potenciais ataques. Quando é notificado imediatamente, pode responder e mitigar um problema rapidamente.
Conclusão
Analisámos o caso de uma página de início de sessão com uma pergunta de segurança em branco. À primeira vista, parece uma página estranha que, em última análise, é inútil. Mas os atacantes podem explorar vulnerabilidades como esta para desperdiçar os seus recursos e potencialmente deitar abaixo o seu sistema. A página da pergunta de segurança é apenas um exemplo de tal vulnerabilidade.
Se conceber as suas aplicações com a segurança em mente e adotar práticas de codificação seguras, então está a começar bem. No entanto, as suas aplicações também necessitam de medidas de segurança implementadas ao nível do sistema e da infraestrutura - como a utilização de um WAF, limitação de taxas, monitorização contínua e alertas. Com as medidas de segurança adequadas em vigor, pode reduzir significativamente o risco de ser alvo de tais ataques.
Para obter mais orientações e dicas sobre como proteger seus aplicativos, confira os documentos do 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