Versión corta:
- Los scripts de shell requieren más precaución con la entrada no confiable; hay peligros inherentes.
- Los scripts de shell no son lenguajes de propósito general, y probablemente no son adecuados para "analizar datos no confiables en redes"
- Todo lo dicho, los scripts de shell pueden hacer increíbles cantidades de cosas, y pueden hacerlo de forma segura con suficiente cuidado. Should es un asunto diferente, y se deja al programador para determinar ...
Versión larga:
Consulte la sección "Ataques de inyección" de este Shell Scripting Primer . Debido a que los datos a menudo se pasan a través de variables y líneas de comando, y debido a que las líneas de comando se combinan y analizan en formas que fueron diseñadas para ser poderosas pero confiables para el usuario, se debe tener especial cuidado en los scripts de shell (en lugar de los lenguajes de propósito general). que separan más cuidadosamente las variables de la ejecución del proceso).
Considere este script:
#!/bin/bash
echo -n "String: "
read BADE
echo $BADE
Y mírame correr:
$ ./foo.sh
String: hello
hello
$ ./foo.sh
String: -n hello
hello$
Observe que en la segunda ejecución de foo.sh, el "-n" que ingresé como parte de la cadena de entrada del usuario se trata como un argumento de línea de comando por el comando echo. Como resultado, no hay una nueva línea entre "hello" y el indicador "$", como ocurrió en la primera ejecución de foo.sh.
Si bien es posible sanear la entrada del usuario, hacerlo en bash significa usar herramientas que pueden ser vulnerables a este tipo de manipulación (considere 'echo $ INPUT | tr -d ...'). En general, el hecho de que bash no sea un lenguaje de propósito general significa que hacer algo generalmente requiere la invocación de otros programas, y no se puede pensar solo en la seguridad de bash, sino también en la seguridad de todos los programas a los que llama.
En bash, las interfaces de llamada de subprograma se analizan en lugar de definirse de manera programática. En la mayoría de los lenguajes de programación de propósito general, hay una distinción más clara entre datos y código. Las cadenas pasadas a las funciones se pasan como una cadena, no como una serie de tokens que se analizan en busca de posibles variables de función antes de ser tratadas como datos. Entonces, sí, bash es "menos recomendable para algunas tareas, como analizar datos no confiables en redes".
"Inherentemente menos seguro" no es una frase que creo que debería usarse. Cada lenguaje de programación en la faz de la tierra tiene puntos fuertes y puntos débiles. Si estoy programando en C, debo tener mucho cuidado con la asignación de memoria y los límites, porque el lenguaje no lo es. En Bash, la asignación de memoria y los límites se manejan para mí, pero debo preocuparme por que los canales de datos y comandos se mezclen fácilmente. Y esta entrevista con Guido van Rossum muestra cómo con Python el intérprete ha estado sujeto a la investigación de problemas de seguridad y cuando se le preguntó "cuándo 'es suficiente' en términos de endurecer al intérprete" respondió "No es así como lo abordamos. que la seguridad es un esfuerzo continuo ... "
Este tipo de pregunta siempre es difícil porque es subjetivo. Si eres un experto en bash, ¿deberías escribir en Python, lo que quizás no sepas? ¿O su conocimiento de cómo funciona bash le ayudará a evitar las trampas? Y tu respuesta va a ser diferente a la de él, a la de ella, que a cualquier otra persona que lea esto. Hay gente por ahí que ha escrito servidores de red increíbles en bash, sin duda; es posible, así que nunca digas que no se puede hacer.
La verdad objetiva es : conozca sus idiomas, conozca sus fortalezas y debilidades, y elija la adecuada para el trabajo . Y trate de aprender continuamente cómo hacerlo de manera segura porque "la seguridad es un esfuerzo continuo".