CWE-89

O produto constrói todo ou parte de um comando SQL usando entrada influenciada externamente vinda de um componente upstream, mas não neutraliza ou neutraliza incorretamente elementos especiais que poderiam modificar o comando SQL pretendido quando ele é enviado a um componente downstream. Sem a remoção ou o uso de aspas suficiente da sintaxe SQL em entradas controláveis pelo usuário, a consulta SQL gerada pode fazer com que essas entradas sejam interpretadas como SQL em vez de dados comuns do usuário.

Consequências comuns

• Confidencialidade, Integridade, Disponibilidade → Executar Código ou Comandos Não Autorizados
• Confidencialidade → Ler Dados da Aplicação
• Autenticação → Obter Privilégios ou Assumir Identidade, Contornar Mecanismo de Proteção
• Controle de Acesso → Contornar Mecanismo de Proteção
• Integridade → Modificar Dados da Aplicação

Mitigações

• Arquitetura e Design: Use uma biblioteca ou framework comprovado que não permita a ocorrência dessa fraqueza ou que forneça construções que facilitem evitá-la [REF-1482]. Por exemplo, considere usar camadas de persistência como Hibernate ou Enterprise Java Beans, que podem prover proteção significativa contra SQL injection se usadas corretamente.
• Arquitetura e Design: Se disponível, use mecanismos estruturados que imponham automaticamente a separação entre dados e código. Esses mecanismos podem ser capazes de prover o devido uso de aspas, codificação e validação automaticamente, em vez de depender do desenvolvedor para fornecer essa capacidade em cada ponto onde a saída é gerada. Processe consultas SQL usando prepared statements, consultas
• Arquitetura e Design, Operação: Execute seu código usando os menores privilégios necessários para realizar as tarefas exigidas [REF-76]. Se possível, crie contas isoladas com privilégios limitados que sejam usadas apenas para uma única tarefa. Dessa forma, um ataque bem-sucedido não dará imediatamente ao atacante acesso ao restante do software ou de seu ambiente. Por exemplo, aplicações de banco d
• 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: Embora seja arriscado usar strings de consulta, código ou comandos gerados dinamicamente que misturam controle e dados, às vezes isso pode ser inevitável. Coloque os argumentos entre aspas adequadamente e escape quaisquer caracteres especiais dentro desses argumentos. A abordagem mais conservadora é escapar ou filtrar todos os caracteres que não passem por uma allowlist extremamente
• 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