Inyección de comandos y argumentos

Una aplicación puede pedir a otro programa que reduzca una imagen o genere un informe. Importa cómo le entrega la petición. Una shell interpreta lenguaje de comandos; un programa interpreta sus propios argumentos. Ambos pueden dar un significado indebido a datos no confiables si la interfaz no conserva la intención.

Dos fronteras distintas

La inyección de shell convierte datos en sintaxis de shell. La inyección de argumentos puede ocurrir sin shell: un valor puede interpretarse como opción o cambiar la conducta del programa. Puede alterar una operación existente sin iniciar otro proceso.

Una lista de argumentos evita una forma de construir cadenas, pero no vuelve aceptable cualquier valor. Ejecutable, opciones, nombres de archivo e interpretación propia del programa necesitan un contrato explícito. Las API varían según plataforma: verifica las garantías del entorno real sin asumir que todas funcionan como POSIX.

Escenario: el servicio de fotografías

El servicio recibe una foto y permite elegir miniatura pequeña o grande. Una biblioteca puede evitar iniciar un proceso. Si hace falta un conversor externo, el servidor elige el ejecutable y traduce esas dos opciones a parámetros fijos. Los datos quedan separados, con límites de tipo, tamaño y ubicación.

Un marcador de fin de opciones puede ayudar si el programa lo admite, pero no es universal ni valida el archivo o su contenido. Una biblioteca también requiere gestionar vulnerabilidades, tratamiento de archivos y consumo de recursos.

La autoridad depende del contexto

El programa suele heredar un contexto de servicio, salvo que un intermediario, suplantación o cambio de privilegios lo modifique. Puede incluir grupos, capacidades, restricciones, datos montados y credenciales disponibles. Un contenedor no implica automáticamente fallo de aislamiento ni acceso completo al host.

La configuración del servicio y la evidencia autorizada de despliegue permiten conocer estas propiedades. No hace falta demostrar ejecución de comandos solo para explicar los permisos previstos.

Evidencia y prevención

Un retraso o error no demuestra ejecución por sí solo. Revisa la ruta de llamadas y los diagnósticos del responsable. Separa comportamiento confirmado de acceso potencial.

Prefiere una biblioteca adecuada; si necesitas un programa, controla ejecutable y argumentos y aplica validación positiva. Restringe archivos y red, y limita tiempo, memoria y salida. Los registros deben conservar identificadores y motivos útiles, ocultando secretos y argumentos sensibles. Registrar todos los argumentos literalmente puede crear otra exposición.

La idea duradera es eliminar intérpretes innecesarios y limitar los restantes, no ampliar indefinidamente una lista de caracteres prohibidos.

Revisa un contrato de miniaturas

El equipo ficticio de fotos necesita exactamente dos tamaños. Su diseño propuesto utiliza un conversor fijo elegido por el servidor, lo inicia mediante una interfaz de argumentos estructurados sin shell y acepta un campo de opciones libre de la petición. El trabajador puede leer la entrada asignada y escribir en un área temporal de salida.

Eliminar el shell aborda la interpretación de su lenguaje, pero el campo libre sigue delegando comportamiento del conversor al solicitante. La función necesita elegir tamaño, no opciones arbitrarias. Mapea las dos elecciones admitidas a ajustes del servidor y rechaza las demás. Comprueba también las garantías concretas del entorno para iniciar procesos.

PrediceEl equipo sustituye el campo libre por pequeño y grande. ¿Basta para aprobar todo el diseño del trabajador?

Aborda la selección de opciones identificada. Decodificación, ubicación de salida, autoridad efectiva, tiempo límite, memoria y limpieza necesitan evidencia propia. La corrección no establece esas otras propiedades.

Considera límites de aceptación aportados: cada trabajo debe terminar en un máximo de cinco segundos, usar como máximo 128 MiB de memoria del trabajador y no dejar salida después de fallar. Un registro de validación del propietario informa cuatro segundos, 96 MiB y un archivo de salida abandonado. Tiempo y memoria cumplen; la limpieza tras el fallo no. Cumplir en una dimensión no compensa incumplir otra.

Una biblioteca reutilizable podría eliminar el inicio de procesos, pero aún decodificaría entradas no confiables y consumiría recursos. Compara las interfaces por su trabajo y autoridad necesaria, sin tratar ninguna etiqueta de implementación como garantía.

El revisor puede escribir un resultado concreto: restringir opciones, conservar la identidad de servicio limitada y exigir evidencia de limpieza conforme al contrato. Nada en estos registros establece que se ejecutara un comando no autorizado.