CWE-88

O produto constrói uma string para um comando a ser executado por um componente separado em outra esfera de controle, mas não delimita adequadamente os argumentos, opções ou switches pretendidos dentro dessa string de comando.

Ao criar comandos usando interpolação em uma string, os desenvolvedores podem assumir que apenas os argumentos/opções que eles especificam serão processados. Essa suposição pode ser ainda mais forte quando o programador codificou o comando de uma maneira que impede que comandos separados sejam fornecidos maliciosamente, por exemplo, no caso de metacaracteres do shell. Ao construir o comando, o desenvolvedor pode usar espaços em branco ou outros delimitadores que são necessários para separar argumentos no comando. No entanto, se um atacante conseguir fornecer uma entrada não confiável que contenha delimitadores de separação de argumentos, então o comando resultante terá mais argumentos do que o pretendido pelo desenvolvedor. O atacante pode então conseguir alterar o comportamento do comando. Dependendo da funcionalidade suportada pelos argumentos supérfluos, isso pode ter consequências relevantes para a segurança.

Consequências comuns

• Confidencialidade, Integridade, Disponibilidade, Outro → Executar Código ou Comandos Não Autorizados, Alterar Lógica de Execução, Ler Dados da Aplicação, Modificar Dados da Aplicação

Mitigações

• Implementação: Sempre que possível, evite construir uma única string que contenha o comando e seus argumentos. Algumas linguagens ou frameworks possuem funções que suportam especificar argumentos independentes, por exemplo, como um array, que é usado para realizar automaticamente o devido uso de aspas ou escape ao construir o comando. Por exemplo, em PHP, escapeshellarg() pode ser usado para escap
• Arquitetura e Design: Compreenda todas as áreas potenciais por onde entradas não confiáveis podem entrar no seu produto: parâmetros ou argumentos, cookies, qualquer coisa lida da rede, variáveis de ambiente, cabeçalhos de requisição bem como conteúdo, componentes de URL, e-mail, arquivos, bancos de dados e quaisquer sistemas externos que forneçam dados à aplicação. Realize a validação de entrada e
• 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
• Implementação: Converta diretamente seu tipo de entrada para o tipo de dado esperado, como usar uma função de conversão que traduz uma string em um número. Após converter para o tipo de dado esperado, garanta que os valores da entrada estejam dentro da faixa esperada de valores permitidos e que as consistências entre múltiplos campos sejam mantidas.
• Implementação: As entradas devem ser decodificadas e canonizadas para a representação interna atual da aplicação antes de serem validadas (CWE-180, CWE-181). Certifique-se de que sua aplicação não decodifique inadvertidamente a mesma entrada duas vezes (CWE-174). Tais erros poderiam ser usados para contornar esquemas de allowlist, introduzindo entradas perigosas depois que elas já foram verificada
• Implementação: Ao trocar dados entre componentes, garanta que ambos os componentes estejam usando a mesma codificação de caracteres. Garanta que a codificação apropriada seja aplicada em cada interface. Defina explicitamente a codificação que você está usando sempre que o protocolo permitir.