Tengo una instancia en la que tenemos una aplicación que requiere la capacidad de configurar comandos sftp que son especificados por los usuarios administrativos. Se configuran a través del front-end de la aplicación. Veracode ha identificado correctamente un ataque de cruce de directorios aquí.
Trabajo para una empresa B2B, y este proceso sftp es para que nuestros clientes envíen / reciban archivos que especifiquen estructuras de directorios en su propio sistema.
La conexión se maneja a través de una API y la biblioteca actual escapa correctamente los datos como entrada (es decir, si envío "../ & & rm *", se trata como un directorio a "cd" a. El archivo de destino para ser copiado, el sistema lo controla explícitamente, pero eso no significa que siempre sea así.
Pero, a falta de una lista negra de ciertos directorios, las rutas como "../" me pierden en cuanto a otras estrategias en el nivel de aplicación que posiblemente pueda usar para evitar este ataque.
Información adicional
Podría haber estado mal comunicado: el problema es que nuestra aplicación se ejecuta en nuestros servidores como su propia instancia. Chroot jails está bien en nuestro extremo, pero ¿qué pasa con el servidor del cliente? La lógica empresarial es que depositaremos los archivos en un directorio en un sistema que especifiquen. No tenemos control sobre eso, y deberían tener la flexibilidad para poder especificar con precisión en qué directorio quieren que nuestra aplicación deposite sus archivos.
No me gustan los enfoques de listas negras porque nunca sabes lo que te perdiste. Y, en teoría, este proceso podría configurarse para apuntar a un cuadro de Windows en lugar de a un cuadro de Unix, y luego hay dos conjuntos de reglas de lista negra que de repente tiene que codificar, sin mencionar la detección del entorno en el servidor remoto.