A9 Denial of Service
Origem: OWASP Chapter Brasil, a enciclopédia livre.
Conteúdo |
A9.1 Descrição
Aplicações WEB são especialmente suscetíveis a ataques de denial of service. Note que ataques de denial of service a redes, como SYN floods, são um tipo de problema que não está conteplado no escopo deste documento.
Uma aplicação WEB não pode facilmente mostrar a diferença entre um ataque e um tráfego normal. Existem muitos fatores que contribuem para essa dificuldade, mas o mais importante é que, por inúmeras razões, o endereço IP não é útil como uma credencial de identificação, pois não existe uma maneira confiável de identificar a procedência de uma requisição HTTP, é muito difícil filtrar tráfegos maliciosos. Para ataques distribuídos, como uma aplicação revelaria a diferença entre um ataque real, múltiplos usuários recarregando a página ao mesmo tempo (fato que pode acontecer se ocorrer um problema temporário com o site), ou ser “slashdotted”?
Em circunstâncias normais, a maioria dos servidores WEB pode suportar centenas de usuários concomitantemente. Um único atacante de um único host pode gerar tráfego suficiente para degradar várias aplicações. O recurso de balanceamento de carga pode dificultar tais ataques, mas não torná-los impossíveis, especialmente se as sessões estiverem vinculadas a um servidor em particular. Esta é uma boa razão para fazer os dados das sessões das aplicações os menores possíveis e também dificultar o início de uma nova sessão.
Uma vez que um atacante pode consumir tudo de algum recurso requerido, também pode prevenir que usuários legítimos usem o sistema. Alguns recursos limitados incluem banda, conexões com bancos de dados, armazenamento em disco, CPU, memória, threads ou recursos específicos da aplicação. Todos esses recursos podem ser consumidos por ataques que os alvejam. Por exemplo, um site de fórum que autoriza usuários não autenticados a lerem e escreverem pode gerar muitas entradas em bancos de dados para cada requisição HTTP que receba. Um atacante pode facilmente mandar tantas requisições que o pool de conexões ao banco de dados pode ficar cheio e nenhuma conexão livre restará a usuários legítimos.
Outras variantes desses ataques miram recursos do sistema relacionados a um usuário em particular. Por exemplo, um atacante pode “deixar de fora” um usuário legítimo mandando credenciais inválidas ao sistema até que trave a conta. Ou o atacante pode solicitar uma nova senha para um usuário, forçando o mesmo a acessar sua conta de email para obter acesso de novo. Alternativamente, se o sistema trava qualquer recurso para um único usuário, então um atacante poderia potencialmente vinculá-los, de modo que outros usuários não pudessem usá-los.
Algumas aplicações WEB são tão suscetíveis a ataques que eles as desligariam imediatamente. Aplicações que não manuseiam erros devidamente podem, inclusive, tornar indisponível a aplicação web. Esses tipos de ataques são particularmente devastadores porque eles instantaneamente impedem todos os outros usuários de usarem a aplicação.
Há uma enorme variedade desses ataques, a maioria pode facilmente ser lançada com algumas poucas linhas de código perl de um computador pouco potente. Enquanto não há defesa perfeita para esses ataques, é possível torná-los mais difíceis de serem bem sucedidos.
A9.2 Ambientes Afetados
Todos os servidores web, servidores de aplicações e ambientes de aplicações web são suscetíveis a ataques denial of service.
A9.3 Exemplos e Referências
- Guia OWASP para Construção de Aplicações Web Seguras e Web Services http://www.owasp.org/documentation/guide/
A9.4 Como Determinar Se Você É Vulnerável
Uma das partes mais difíceis de ataques de denial of service é determinar se você é vulnerável. Ferramentas de testes de carga, como o JMeter pode gerar tráfego web então você pode testar certos aspectos de como seu site se comporta sobre uma alta carga. Certamente um teste importante é saber quantas requisições por segundo sua aplicação pode suportar. Testar de um único endereço IP é útil, pois oferece uma estimativa de quantas requisições um atacante tem de gerar para causar dano a seu site.
Para determinar se algum recurso pode ser usado para criar um denial of service, você deve analisar cada um para ver existe uma maneira de exauri-lo. Você deve particularmente focar o que usuários não autenticados podem fazer. Entretanto, a não ser que você confie em todos os seus usuários, também deve examinar o que os usuários autenticados podem fazer.
A9.5 Como Se Proteger
Defender-se contra ataques de denial of service é difícil, pois não existe uma maneira infalível de se proteger contra esses ataques.
Como regra geral, deve-se limitar os recursos alocados a qualquer usuário para o mínimo possível. Para usuários autenticados, é possível estabelecer quotas, então você pode limitar a quantidade de carga que um usuário gera em seu sistema. Em particular, você pode considerar somente o manuseio de uma requisição por usuário por vez sincronizando com a sessão do usuário. Você também pode considerar desconsiderar qualquer requisição em processamento de um usuário quando uma outra requisição desse mesmo usuário chegar.
For unauthenticated users, you should avoid any unnecessary access to databases or other expensive resources. Try to architect the flow of your site so that an unauthenticated user will not be able to invoke any expensive operations. You might consider caching the content received by unauthenticated users instead of generating it or accessing databases to retrieve it.
Para usuários não autenticados, você deve evitar qualquer acesso desnecessário ao banco de dados ou outro recurso oneroso. Tente estruturar o fluxo de seu site para que um usuário não autenticado não consiga chamar nenhuma operação onerosa. Você pode considerar cachear o conteúdo recebido por usuários não autenticados em vez gerá-los ou acessar bancos de dados para recuperá-los.
Você também deve checar seu esquema de manuseio de erros para se certificar que um erro não pode afetar a operação da aplicação.
© 2005 The OWASP Foundation | Contact the site admin with comments/questions concerning this site.