Prevención de inyección de comandos y argumentos

Bash es un potente lenguaje de unión: pasa texto directamente al kernel, a otros programas y a sub-shells. Esa potencia se convierte en una vulnerabilidad en cuanto una entrada no fiable llega a un comando sin validación ni comillas.

Dos causas fundamentales provocan prácticamente todas las inyecciones en Bash:

• División de palabras: las variables sin comillas se dividen por los espacios en blanco (IFS), transformando un valor lógico en varios tokens del shell.
• Expansión de glob: caracteres como *, ? y [ son expandidos por el shell antes incluso de que se ejecute el comando.

Un atacante que controle un nombre de archivo, un nombre de usuario, un parámetro de URL o una variable de entorno puede aprovechar ambos mecanismos para ejecutar comandos arbitrarios, leer archivos o escalar privilegios.

En esta lección se muestra exactamente cómo aparecen estas vulnerabilidades y, lo que es más importante, cómo eliminarlas mediante el uso correcto de comillas, la validación de entradas y el paso de argumentos mediante arrays.

Cuando Bash encuentra una variable sin comillas, divide su valor usando cualquier carácter incluido en $IFS (por defecto: espacio, tabulador y salto de línea). Lo que parece un solo argumento se convierte en varios.

Ejecute el script siguiente y observe cómo un nombre de archivo con un espacio se convierte en dos argumentos independientes para rm.

La defensa más sencilla y eficaz contra la división de palabras consiste en usar siempre comillas dobles en las expansiones de variables.

• "$var": se expande exactamente a un token, conservando los espacios, tabuladores y saltos de línea.
• 'literal': comillas simples; no realizan ninguna expansión y son útiles para cadenas fijas.
• No use nunca $var sin comillas, a menos que necesite explícitamente la división de palabras y la expansión de glob.

El script siguiente muestra la versión segura del ejemplo anterior.

Las variables sin comillas también están sujetas a la expansión de nombres de ruta (glob). Si la entrada controlada por el usuario contiene * o ?, Bash la expande comparándola con el sistema de archivos antes de ejecutar el comando.

Un vector de ataque clásico: un formulario web establece PATTERN=* y el script ejecuta cp $PATTERN /tmp/leak/, copiando todos los archivos del directorio actual.

La solución es idéntica: poner la variable entre comillas dobles. Una variable "$PATTERN" entre comillas se pasa literalmente; el shell nunca realiza la expansión de glob sobre ella.

Los scripts que aceptan argumentos del proceso que los invoca son objetivos principales de inyección. Cada parámetro posicional ($1, $2, ...) debe llevar comillas en todos los lugares donde se utilice.

Un patrón especialmente peligroso consiste en pasar $@ o $* sin comillas a otro comando:

• "$@": expande cada parámetro posicional como una palabra independiente y con sus propias comillas. Use siempre esta forma.
• $@ o $* sin comillas: están sujetos a la división de palabras y a la expansión de glob.
• "$*": une todos los parámetros en una sola palabra (rara vez es lo que necesita).

eval vuelve a analizar su argumento como código del shell. Cualquier dato no fiable que llegue a eval puede ejecutar comandos arbitrarios.

Patrones peligrosos habituales:

• eval "$user_input"
• eval echo \$$var (búsqueda indirecta de variables)
• Pasar datos del usuario mediante bash -c "$input"

Regla: no pase nunca entradas no fiables a eval ni a bash -c. Use alternativas seguras de Bash:

• Expansión indirecta: ${!varname} en lugar de eval echo \$$varname
• Arrays asociativos para búsquedas dinámicas de clave-valor
• Funciones en lugar de cadenas de comandos generadas

Rechazar caracteres conocidos como peligrosos (una lista de bloqueados) es frágil: los atacantes encuentran codificaciones o caracteres que usted ha olvidado. En su lugar, use una lista de permitidos: acepte únicamente los caracteres que sabe que son seguros.

Estrategias de listas de permitidos en Bash:

• Coincidencia con una expresión regular: [[ "$input" =~ ^[A-Za-z0-9_-]+$ ]]
• Coincidencia con un patrón: case "$input" in [A-Za-z0-9]*) ... ;; esac
• Comprobación de enumeración: compare con un conjunto fijo de valores válidos

Valide en el límite, tan pronto como la entrada entre en el script, antes de que llegue a cualquier comando.

Cuando necesite construir un comando dinámicamente —añadiendo flags de forma condicional o recorriendo entradas— use un array de Bash en lugar de concatenar cadenas.

La concatenación de cadenas elimina toda la estructura; un array de Bash conserva cada argumento como un elemento independiente, sin que el shell vuelva a analizarlo.

• Declarar: args=()
• Añadir: args+=(--flag "$value")
• Ejecutar: command "${args[@]}"

"${args[@]}" expande cada elemento como una palabra independiente y con sus propias comillas, exactamente igual que "$@".

Incluso un argumento entre comillas correctamente puede interpretarse como un flag de opción si comienza por -. Considere rm "$file" cuando file='-rf .': las comillas protegen contra la división de palabras, pero rm sigue interpretando -rf como flags.

La convención POSIX -- indica el fin de las opciones a la mayoría de las utilidades GNU/BSD. Todo lo que aparece después de -- se trata como un argumento posicional, nunca como un flag.

Cuando los scripts de Bash invocan clientes de bases de datos (psql, mysql), curl con URL proporcionadas por el usuario u otras herramientas similares, se aplican dos capas adicionales:

• Consultas parametrizadas: no interpole nunca datos del usuario en cadenas SQL. Pase los valores mediante -v en psql o --data-urlencode en curl.
• Separe los datos del código: use printf con una cadena de formato literal; no permita nunca que la entrada del usuario sea la cadena de formato.

El ejemplo siguiente consulta PostgreSQL de forma segura y mantiene el valor proporcionado por el usuario completamente fuera del texto SQL.

Un script de Bash seguro y listo para producción combina todas las técnicas de esta lección en una defensa coherente y por capas. Esta es una plantilla reforzada mínima pero completa:

• set -euo pipefail: salir en caso de error, tratar las variables no definidas como errores y propagar los fallos de los pipes.
• Validar al inicio: use una lista de permitidos para cada entrada externa antes de que llegue a cualquier comando.
• Poner comillas en todo: "$var", "$@", "${array[@]}"; sin excepciones, a menos que necesite la división de palabras.
• Usar arrays para construir comandos dinámicamente.
• Prefijar los argumentos con -- al pasar nombres de archivo o cadenas proporcionados por el usuario.
• No usar nunca eval con datos no fiables; prefiera ${!var} para búsquedas indirectas.
• Restringir los permisos: ejecute los scripts con los privilegios mínimos necesarios; evite sudo dentro de scripts que acepten entradas del usuario.

Compruebe su comprensión de los conceptos clave de esta lección.

Ha estudiado el conjunto completo de herramientas defensivas para gestionar entradas de Bash de forma segura:

• La división de palabras y la expansión de glob son los mecanismos fundamentales que convierten las variables inseguras en vectores de inyección.
• Ponga comillas dobles en todas las variables ("$var", "$@", "${arr[@]}") para bloquear ambas amenazas.
• Use "$@" —nunca $@ ni $* sin comillas— al reenviar argumentos.
• Prefije los nombres de archivo proporcionados por el usuario con -- para evitar la inyección de flags.
• Use una lista de permitidos para todas las entradas externas mediante una expresión regular ([[ $v =~ ^pattern$ ]]) antes de que lleguen a cualquier comando.
• Construya comandos dinámicos con arrays (cmd+=() → "${cmd[@]}"), nunca mediante concatenación de cadenas.
• Elimine eval y bash -c "$input"; use ${!varname} para una expansión indirecta segura.
• Abra siempre los scripts con set -euo pipefail y IFS=$'\n\t' como configuración básica reforzada.

Estas prácticas, aplicadas de forma coherente desde la primera línea de cada script, reducen casi a cero la superficie de ataque de Bash frente a vulnerabilidades de la clase de inyección.