A1 Parâmetros não validados
Origem: OWASP Chapter Brasil, a enciclopédia livre.
Conteúdo |
A1.1 Descrição
Aplicações Web utilizam parâmetros de requisições HTTP (e de vez em quando arquivos) para determinar como devem responder. Invasores podem manipular todas as partes de uma requisição HTTP, incluindo a URL, querystring, cabeçalhos, cookies e campos de formulários (inclusive os campos ocultos – hidden), visando driblar os mecanismos de segurança do site. Alguns nomes comuns de ataques de manipulação de parâmetros são: Navegação forçada, command injection, cross site scripting, buffer overflows, ataques de format string, SQL injection, envenenamento de cookies (cookie poisoning) e manipulação de campos ocultos. Cada um destes ataques é descrito com mais detalhes na sequência deste texto.
- A4 – Falhas de Cross Site Scripting: discute parâmetros que contém scripts para serem executados no browser de outros usuários
- A5 – Buffer Overflows: discute parâmetros que são montados para sobrescrever o espaço de memória utilizado para execução de programas
- A6 – Falhas de Injection: discute a inclusão de comandos executáveis através de alterações em parâmetros
Alguns sites tentam se proteger filtrando parâmetros maliciosos. O problema nesta abordagem é a existência de diversas formas de se codificar informações. Esses padrões de codificação não são como a criptografia, pois a decodificação é trivial (não são necessárias chaves). Ainda assim, desenvolvedores as vezes esquecem de decodificar todos os parâmetros antes de utilizá-los. Parâmetros devem ser convertidos para sua forma mais simples antes de serem validados, pois caso contrário códigos maliciosos podem passar desapercebidos pelos filtros. O processo de decodificar e simplificar o formato dos parâmetros é chamado de “canonicalização” (canonicalization). Como quase todos os parâmetros HTTP podem ser representados em vários formatos, a codificação pode ser utilizada para tentar esconder qualquer ataque que vise as vulnerabilidades descritas neste documento. Isso faz com que a filtragem seja muito difícil.
Um número surpreendente de aplicações Web utiliza apenas mecanismos no lado do cliente para validar parâmetros de entrada. É simples escapar da validação no lado do cliente, deixando a aplicação desprotegida contra parâmetros maliciosos. Invasores podem gerar suas próprias requisições HTTP utilizando ferramentas simples, como o telnet. Eles não precisam se preocupar com nada que o desenvolvedor pretendia que acontecesse no lado do cliente. A verificação no navegador é uma boa idéia sob o ponto de vista de performance e facilidade de uso, mas não traz benefícios em termos de segurança. Verificações no lado do servidor são necessárias para se defender contra ataques de manipulação de parâmetros. Após a implementação dos controles no lado do servidor, controles do lado do cliente também podem ser implementados para melhorar a experiência de uso por usuários legítimos e reduzir a quantidade de tráfego inválido que chega ao servidor.
Ataques de manipulação de parâmetros estão se tornando mais comuns a medida que a quantidade de ferramentas que permitem testes de corrupção, força bruta e confusão de parâmetros aumenta. O impacto da utilização de parâmetros de entrada não validados não deve ser subestimado. Muitos ataques seriam difíceis ou impossíveis de se executar se os desenvolvedores validassem os parâmetros antes de usá-los. A não ser que a aplicação web tenha um forte mecanismo centralizado para validar todos os parâmetros provenientes de requisições HTTP (e outras fontes), há uma grande chance de vulnerabilidades baseadas em parâmetros maliciosos existirem.
A1.2 Ambientes Afetados
Todos os servidores Web, servidores de Aplicação e ambientes de aplicações Web são suscetíveis à manipulação de parâmetros.
A1.3 Exemplos e referências
- Guia OWASP de Construção de Aplicações Web Seguras, capítulo 8: Validação de Dados (http://www.owasp.org/documentation/guide.html)
- Projeto modsecurity (Módulo de Apache para validação HTTP) (http://www.modsecurity.org)
- Como construir um sistema de validação de requisições HTTP (Validação J2EE com o Stinger) (http://www.owasp.org/columns/jeffwilliams/jeffwilliams2.html)
- Have Your Cake and Eat it Too (Validação para .NET) (http://www.owasp.org/columns/jpoteet/jpoteet2.html)
A1.4 Como identificar se você está vulnerável
Qualquer parte da requisição HTTP que é usada por uma aplicação web sem antes ser cuidadosamente validada é conhecida como um parâmetro “sujo” (tainted). A maneira mais simples de se identificar o uso de parâmetros sujos é através de uma revisão detalhada de código, procurando por chamadas nas quais informações são extraídas de uma requisição HTTP. Em uma aplicação J2EE, por exemplo, seriam os métodos na classe HttpServletRequest. Basta então seguir o código até descobrir onde aquela variável é utilizada. Se a variável não é verificada antes de ser utilizada, é muito provável que haja um problema. Em Perl, considere utilizar a opção “taint” (-T).
Também é possível identificar o uso de parâmetros sujos através de ferramentas como o OWASP WebScarab. Ao enviar valores inesperados nas requisições HTTP e observando as respostas da aplicação, você pode identificar situações onde parâmetros sujos são utilizados.
A1.5 Como se proteger
A melhor forma de se proteger da manipulação de parâmetros é garantir que todos eles serão validados antes de serem utilizados pela aplicação. Um componente centralizado ou biblioteca única costuma ser a abordagem mais efetiva, com o código que faz a validação em um único local. Cada parâmetro deve ser checado de acordo com uma definição precisa de quais entradas podem ser aceitas. Abordagens “negativas”, que envolvem a busca por padrões considerados maliciosos ou baseadas em assinaturas não costumam ser efetivas, e tendem a ter uma manutenção complexa.
Parâmetros devem ser validados de acordo com uma especificação “positiva” que define:
- Tipo de dado (string, inteiro, real, etc…)
- Conjunto de caracteres aceito
- Tamanho mínimo e máximo
- Se o conteúdo “nulo” é aceito
- Se a existência do parâmetro é mandatória ou não
- Se a existência de duplicados é permitida
- Faixa de valores numéricos
- Valores específicos (enumeração, como para nomes de meses, por exemplo)
- Padrões específicos (expressões regulares)
Um novo tipo de sistema de segurança, os firewalls de aplicações web, podem prover alguns serviços de validação de parâmetros. Porém, para que sejam eficazes, devem ser configurados com uma definição clara do que é válido para cada parâmetro de seu site. Isso inclui proteger todos os tipos de entrada provenientes de uma requisição HTTP, incluindo URLs, formulários, cookies, querystrings, campos ocultos e parâmetros.
O projeto de Filtros OWASP está criando um conjunto de componentes reutilizáveis em diversas linguagens de programação para ajudar a prevenir contra várias formas de manipulação de parâmetros. O sistema de validação de requisições HTTP Stinger (stinger.sourceforge.net) também foi desenvolvido pelo OWASP para ambientes J2EE.