CWE-88

El producto construye una cadena para un comando que será ejecutado por un componente separado en otra esfera de control, pero no delimita adecuadamente los argumentos, opciones o modificadores previstos dentro de esa cadena de comando.

Al crear comandos mediante la interpolación en una cadena, los desarrolladores pueden suponer que solo se procesarán los argumentos/opciones que ellos especifiquen. Esta suposición puede ser aún más fuerte cuando el programador ha codificado el comando de una manera que impide que se proporcionen comandos separados de forma maliciosa, por ejemplo, en el caso de los metacaracteres del shell. Al construir el comando, el desarrollador puede usar espacios en blanco u otros delimitadores que se requieren para separar los argumentos del comando. Sin embargo, si un atacante puede proporcionar una entrada no confiable que contenga delimitadores separadores de argumentos, entonces el comando resultante tendrá más argumentos de los previstos por el desarrollador. El atacante puede entonces ser capaz de cambiar el comportamiento del comando. Dependiendo de la funcionalidad admitida por los argumentos adicionales, esto puede tener consecuencias relevantes para la seguridad.

Consecuencias comunes

• Confidencialidad, Integridad, Disponibilidad, Otro → Ejecución de código o comandos no autorizados, Alteración de la lógica de ejecución, Lectura de datos de la aplicación, Modificación de datos de la aplicación

Mitigaciones

• Implementación: Cuando sea posible, evite construir una única cadena que contenga el comando y sus argumentos. Algunos lenguajes o marcos tienen funciones que admiten especificar argumentos independientes, por ejemplo, como un arreglo, que se utiliza para realizar automáticamente el entrecomillado o escape apropiado al construir el comando. Por ejemplo, en PHP, escapeshellarg() puede usarse para e
• Arquitectura y diseño: Comprenda todas las áreas potenciales donde pueden ingresar entradas no confiables en su producto: parámetros o argumentos, cookies, cualquier cosa leída de la red, variables de entorno, encabezados de solicitud así como el contenido, componentes de URL, correo electrónico, archivos, bases de datos y cualquier sistema externo que proporcione datos a la aplicación. Realice la
• Implementación: Suponga que toda entrada es maliciosa. Utilice una estrategia de validación de entradas de tipo "aceptar lo que se sabe que es válido", es decir, use una lista de entradas aceptables que se ajusten estrictamente a las especificaciones. Rechace cualquier entrada que no se ajuste estrictamente a las especificaciones, o transfórmela en algo que sí lo haga. Al realizar la validación de
• Implementación: Convierta directamente su tipo de entrada al tipo de datos esperado, como usar una función de conversión que traduzca una cadena en un número. Después de convertir al tipo de datos esperado, asegúrese de que los valores de la entrada se encuentren dentro del rango esperado de valores permitidos y de que se mantengan las coherencias entre múltiples campos.
• Implementación: Las entradas deben decodificarse y canonicalizarse a la representación interna actual de la aplicación antes de ser validadas (CWE-180, CWE-181). Asegúrese de que su aplicación no decodifique inadvertidamente la misma entrada dos veces (CWE-174). Tales errores podrían utilizarse para eludir los esquemas de lista de permitidos introduciendo entradas peligrosas después de que se haya
• Implementación: Al intercambiar datos entre componentes, asegúrese de que ambos componentes utilicen la misma codificación de caracteres. Asegúrese de que se aplique la codificación adecuada en cada interfaz. Establezca explícitamente la codificación que está utilizando siempre que el protocolo se lo permita.