¿Permitir que una aplicación web mueva, copie y / o elimine archivos fuera de la raíz del servidor puede ser un problema de seguridad?

Si la entrada del usuario no tiene influencia en los comandos o sus argumentos, no debería haber una amenaza inmediata.

Pero siempre es un riesgo, es posible que le falte algo o que haya vulnerabilidades desconocidas (es decir, existen) en el software que está utilizando (por ejemplo, Django).

Lo que haría para mitigar esos casos sería:

1. Verifique sus permisos. Asegúrese de usar los privilegios mínimos necesarios para las operaciones que necesita (tal vez el usuario de Apache tenga privilegios demasiado altos para lo que necesita, cree otro usuario con menos privilegios);
2. En la lista blanca solo los comandos que va a necesitar (bloquear todo lo demás);
3. Busque la configuración de un sistema de archivos controlado para esas operaciones (por ejemplo, algún tipo de 'chroot');
4. Endurezca su servidor (busque en Grsecurity y RBAC);
5. Obviamente, mantenga todo actualizado y actualizado.

Cuando crea comandos que incluyen cadenas proporcionadas por el usuario, siempre existe un riesgo de inyección de comandos.

Código de ejemplo que se supone que copia un archivo a un nombre proporcionado por el usuario:

$command = "cp template.png " + $filename + ".png";

Cuando el usuario proporciona el nombre del archivo, pueden pasar esto:

$filename = "foo.png ; rm *";

que resulta en la recepción del SO

cp template.png foo.png ; rm *.png

que en realidad son dos comandos, el segundo es malicioso (elimina todos los archivos png del directorio).

¡Sí, puede! Esto es extremadamente inseguro y se considera una de las mejores prácticas deficientes en la industria de la seguridad. Hay muchas cosas que pueden salir mal:

• Puede dejar que las personas escriban los comandos que deseen, y no pasará mucho tiempo antes de que su servidor descargue y ejecute un binario malicioso de su propia creación.
• Puede sufrir una categoría de ataques como lo describe @Philipp llamado "Injections Command Injections" . Ocurre cuando ejecuta comandos en los datos proporcionados por el usuario, y los usuarios le proporcionan datos para que le agreguen secuencias de comandos adicionales. El mejor enfoque para solucionar este problema es escribir una función que reciba el comando y los datos por separado y siempre desinfecte / escape los datos .
• Incluso si te limitas a algunos comandos como cp y mv, los usuarios pueden proporcionar nombres de archivos que apunten fuera de tu directorio de trabajo, como "/ usr / bin / apache", que en el ejemplo de @ Philipp daría lugar a que tu binario de Apache sea eliminado y su servidor ya no funcionará la próxima vez que lo reinicie.

Ahora, no sé qué intenta hacer, pero si insiste en continuar, tenga en cuenta lo siguiente:

• Autentique a sus usuarios y verifique que estén autorizados para usar su vista
• Solo permite comandos dentro de una lista blanca, y comandos y datos separados como se dijo anteriormente
• Desinfecte los datos de manera sistemática al escapar de caracteres especiales y verificar que pertenece a un espacio legal (por ejemplo, los nombres de archivos están dentro de un espacio legal, que no contienen ningún nombre de carpeta, por ejemplo); vea el modelo de Clark-Wilson
• Sandbox en su servidor web y, si es posible, obtenga un servidor / trabajador específico para ejecutar esta vista especial suya (vea los módulos de SELinux para Apache, especialmente observe cómo RHEL 7 usa SELinux y systemd para los servicios de sandbox); Vaya aún más lejos si el mismo servidor ejecuta algo realmente sensible y contenga el servidor que ejecuta su vista web en un contenedor LXC o Docker (aún no completamente seguro pero mejor que nada)
• Haga que un equipo externo de pruebas de penetración audite su código y su servidor