Tratamento de inputs e Denial of Service

8442476626_33bfb7c564_k

No processo de desenvolvimento nem sempre é comum ver programadores que se dedicam de forma efetiva ao propósito de ajustar determinados detalhes menores do software, pelo contrário, na maioria dos casos, procuram desenvolver algo que diga mais respeito a entregar um projeto funcional dentro das expectativas de usabilidade do cliente, o problema é que quando esses detalhes estão no espectro da segurança da informação, ignorá-los faz de nosso software uma bomba relógio que poderá deixar o cliente na mão a qualquer momento.

Dentre um dos meus conceitos preferidos do submundo da segurança da informação está o de que toda entrada de dados é mal-intencionada até que se prove o contrário. Seguindo esse conceito, em nossas aplicações não iremos estipular quais tipos de dados não podem ser inseridos, mas pelo contrário, deve-se definir uma regra que busca definir que apenas determinados tipos de dados passarão, e tudo que for diferente disso deverá ser barrado por um filtro. E para evitar ataques de Denial Of Service, estando em um ambiente web, devemos ser muito rigorosos ao definir regras para entradas de dado.

Como o ataque do tipo denial of service busca tornar sua aplicação indisponível para os usuários o tipo de erro mais cometido pelos desenvolvedores é não definir um tamanho máximo de caracteres que um usuário pode passar para a aplicação processar, e isso fica pior ainda quando esses dados forem executados no banco de dados através de uma query. Como os bancos de dados naturalmente estipulam um número máximo de conexões, quando inserimos um valor muito grande para o banco de dados processar uma conexão irá ficar aberta por mais tempo, devido à demora de processamento, e se fizermos várias conexões simultâneas do mesmo tipo, podemos atingir o número máximo de conexões ativas do banco de dados e tornar todas as informações armazenadas neste indisponíveis para o usuário.

Portanto, além analisar os tipos de dados, e formatos de informações que podem ser inseridas, devemos também limitar a quantidade de dados que estamos dispostos à permitir aos nossos servidores processarem. Esse é um erro muito recorrente, que encontrei muitas vezes ao longo das minhas experiências com análises de impactos de vulnerabilidades. E geralmente o impacto tem potencial financeiro.


Deixe uma resposta

Your email address will not be published / Required fields are marked *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>