Inyección sobre el sistema operativo

Si no se controla la inyección de código sobre el sistema operativo, podría permitir a atacantes ejecutar los comandos peligrosos directamente sobre el sistema operativo de forma inesperada.

Esta debilidad puede llevar a una vulnerabilidad en entornos en los que el atacante no tiene acceso directo al sistema operativo, como en aplicaciones web. Alternativamente, si la debilidad se produce en un programa privilegiado, podría permitir al atacante especificar comandos que normalmente no serían accesibles o llamar a comandos alternativos con privilegios que el atacante no tiene.

Hay por lo menos dos subtipos de inyección de comandos sobre el sistema operativo:

• La aplicación tiene la intención de ejecutar un programa único, fijo, que se encuentra bajo su control. Tiene la intención de utilizar datos externos proporcionados como argumentos a dicho programa.
• Por ejemplo, el programa podría utilizar el sistema ("nslookup [HOSTNAME]") para ejecutar nslookup y permitir al usuario que proporcione un nombre de host, que se utiliza como un argumento. Los atacantes no pueden impedir que se ejecute nslookup. Sin embargo, si el programa no elimina los separadores de comando desde el argumento HOSTNAME, los atacantes podrían colocar los separadores en los argumentos, lo que les permitiría ejecutar su propio programa nslookup después del anterior.

• La aplicación acepta una entrada que se utiliza para seleccionar qué programa ejecutar, así como los comandos para su uso. La aplicación simplemente redirige este comando entero al sistema operativo.
• Por ejemplo, el programa podría usar "exec ([COMANDO])" para ejecutar el comando [] que fue suministrado por el usuario. Si el comando está bajo control atacante, entonces el atacante puede ejecutar código arbitrario o programas.

El siguiente ejemplo lee el nombre de un script de shell para ejecutarse desde las propiedades del sistema. Está sujeto a la segunda variante de inyección de comandos del sistema operativo. Si un atacante tiene control sobre esta propiedad, entonces podría modificar la propiedad para que apunte a un programa peligroso

String script = System.getProperty("SCRIPTNAME");
if (script != null)
    System.exec(script);

Para evitarlo, suponga que todas las entradas son código malicioso. Es recomendable utilizar una estrategia de validación de entrada "aceptar buena conocida", es decir, utilizar una lista blanca de entradas aceptables que cumpla estrictamente con las especificaciones. Rechazar cualquier entrada que no corresponda estrictamente a las especificaciones, o transformarlo en algo que lo haga. No se confíe exclusivamente en la búsqueda de entradas maliciosas o mal formadas (es decir, no confíe en una lista negra). Sin embargo, las listas negras puede ser útiles para detectar posibles ataques o determinar qué insumos son tan incorrectos que deberían ser rechazadas de plano.

Cuando en la construcción de cadenas de comandos del sistema operativo, se hace uso de listas blancas estrictas que limitan el juego de caracteres basado en el valor esperado del parámetro en la petición. Esta, indirectamente, limita el alcance de un ataque, pero esta técnica es menos importante que la producción adecuada de la codificación y escapar.

Tenga en cuenta que la codificación de salida adecuada, escapando, y marcando es la solución más eficaz para evitar la inyección de comandos del SO, a pesar de que la validación de entrada puede proporcionar una cierta defensa en profundidad. Esto se debe a que limita efectivamente lo que aparecerá en la producción.

La validación de entrada no siempre evita la inyección de comandos OS, especialmente si son necesarias para dar soporte a los campos de texto libre que puede contener caracteres arbitrarios.

Por ejemplo, al invocar un programa de correo, puede ser necesario permitir que el campo "asunto" contenga las entradas de otro tipo de caracteres peligrosos como ";" o ">", los cuales tendrían que ser escapados o manipulados de otra manera.