CWE-20

O produto recebe entrada ou dados, mas não valida ou valida incorretamente se a entrada possui as propriedades necessárias para processar os dados de forma segura e correta.

A validação de entrada é uma técnica frequentemente utilizada para verificar entradas potencialmente perigosas, a fim de garantir que elas sejam seguras para processamento dentro do código ou ao se comunicar com outros componentes. A entrada pode consistir em: - dados brutos - strings, números, parâmetros, conteúdo de arquivos, etc. - metadados - informações sobre os dados brutos, como cabeçalhos ou tamanho. Os dados podem ser simples ou estruturados. Dados estruturados podem ser compostos por muitas camadas aninhadas, formadas por combinações de metadados e dados brutos, com outros dados simples ou estruturados. Muitas propriedades de dados brutos ou metadados podem precisar ser validadas ao entrar no código, tais como: - quantidades especificadas como tamanho, comprimento, frequência, preço, taxa, número de operações, tempo, etc. - quantidades implícitas ou derivadas, como o tamanho real de um arquivo em vez de um tamanho especificado - índices, deslocamentos ou posições em estruturas de dados mais complexas - chaves simbólicas ou outros elementos em tabelas hash, arrays associativos, etc. - boa formação, isto é, correção sintática - conformidade com a sintaxe esperada - correção de tokens léxicos - conformidade com as regras sobre o que é tratado como um token - tipo especificado ou derivado - o tipo real da entrada (ou o que a entrada aparenta ser) - consistência - entre elementos de dados individuais, entre dados brutos e metadados, entre referências, etc. - conformidade com regras específicas do domínio, por exemplo, lógica de negócio - equivalência - garantir que entradas equivalentes sejam tratadas da mesma forma - autenticidade, propriedade ou outras atestações sobre a entrada, por exemplo, uma assinatura criptográfica para comprovar a origem dos dados. Propriedades implícitas ou derivadas dos dados frequentemente precisam ser calculadas ou inferidas pelo próprio código. Erros na derivação de propriedades podem ser considerados um fator contribuinte para a validação imprópria de entrada.

Consequências comuns

• Disponibilidade → DoS: Falha, Encerramento ou Reinicialização, DoS: Consumo de Recursos (CPU), DoS: Consumo de Recursos (Memória)
• Confidencialidade → Ler Memória, Ler Arquivos ou Diretórios
• Integridade, Confidencialidade, Disponibilidade → Modificar Memória, Executar Código ou Comandos Não Autorizados

Mitigações

• Arquitetura e Design: Considere utilizar técnicas de segurança baseadas na teoria de linguagens (LangSec) que caracterizam entradas usando uma linguagem formal e constroem "reconhecedores" para essa linguagem. Isso essencialmente exige que a análise sintática (parsing) seja uma camada distinta que impõe de fato um limite entre a entrada bruta e as representações internas de dados, em vez de permit
• Arquitetura e Design: Utilize um framework de validação de entrada como o Struts ou a API de Validação do OWASP ESAPI. Observe que usar um framework não resolve automaticamente todos os problemas de validação de entrada; fique atento a fraquezas que possam surgir do uso incorreto do próprio framework (CWE-1173).
• Arquitetura e Design, Implementação: Compreenda todas as áreas potenciais por onde entradas não confiáveis podem entrar no produto, incluindo, mas não se limitando a: parâmetros ou argumentos, cookies, qualquer coisa lida da rede, variáveis de ambiente, consultas de DNS reverso, resultados de consultas, cabeçalhos de requisição, componentes de URL, e-mail, arquivos, nomes de arquivos, bancos de da
• Implementação: Assuma que toda entrada é maliciosa. Use uma estratégia de validação de entrada do tipo "aceitar apenas o que é reconhecidamente bom", isto é, use uma lista de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite qualquer entrada que não esteja estritamente em conformidade com as especificações, ou transforme-a em algo que esteja. Ao realizar a
• Arquitetura e Design: Para quaisquer verificações de segurança realizadas no lado do cliente, garanta que essas verificações sejam duplicadas no lado do servidor, a fim de evitar o CWE-602. Os atacantes podem contornar as verificações do lado do cliente modificando os valores após as verificações terem sido realizadas, ou alterando o cliente para remover completamente as verificações do lado do cl
• Implementação: Quando sua aplicação combina dados de múltiplas fontes, realize a validação após as fontes terem sido combinadas. Os elementos de dados individuais podem passar na etapa de validação, mas violar as restrições pretendidas depois de combinados.