CWE-22

El producto utiliza entradas externas para construir un nombre de ruta destinado a identificar un archivo o directorio ubicado debajo de un directorio padre restringido, pero el producto no neutraliza adecuadamente los elementos especiales dentro del nombre de ruta que pueden hacer que este se resuelva en una ubicación fuera del directorio restringido.

Muchas operaciones de archivos están destinadas a realizarse dentro de un directorio restringido. Mediante el uso de elementos especiales como ".." y separadores "/", los atacantes pueden escapar fuera de la ubicación restringida para acceder a archivos o directorios que se encuentran en otra parte del sistema. Uno de los elementos especiales más comunes es la secuencia "../", que en la mayoría de los sistemas operativos modernos se interpreta como el directorio padre de la ubicación actual. Esto se conoce como path traversal relativo. El path traversal también abarca el uso de nombres de ruta absolutos como "/usr/local/bin" para acceder a archivos inesperados. Esto se conoce como path traversal absoluto.

Consecuencias comunes

• Integridad, Confidencialidad, Disponibilidad → Ejecución de código o comandos no autorizados
• Integridad → Modificación de archivos o directorios
• Confidencialidad → Lectura de archivos o directorios
• Disponibilidad → DoS: bloqueo, salida o reinicio

Mitigaciones

• Implementación: Suponga que toda entrada es maliciosa. Utilice una estrategia de validación de entradas de tipo "aceptar lo que se sabe que es válido", es decir, use una lista de entradas aceptables que se ajusten estrictamente a las especificaciones. Rechace cualquier entrada que no se ajuste estrictamente a las especificaciones, o transfórmela en algo que sí lo haga. Al realizar la validación de
• Arquitectura y diseño: Para cualquier verificación de seguridad que se realice en el lado del cliente, asegúrese de que estas verificaciones se dupliquen en el lado del servidor, a fin de evitar CWE-602. Los atacantes pueden eludir las verificaciones del lado del cliente modificando los valores después de que se hayan realizado las verificaciones, o cambiando el cliente para eliminar por completo
• Implementación: Las entradas deben decodificarse y canonicalizarse a la representación interna actual de la aplicación antes de ser validadas (CWE-180). Asegúrese de que la aplicación no decodifique la misma entrada dos veces (CWE-174). Tales errores podrían utilizarse para eludir los esquemas de validación por lista de permitidos introduciendo entradas peligrosas después de que se hayan verificad
• Arquitectura y diseño: Utilice una biblioteca o marco de trabajo verificado que no permita que esta debilidad ocurra o que proporcione construcciones que faciliten evitarla [REF-1482].
• Operación: Utilice un firewall de aplicaciones que pueda detectar ataques contra esta debilidad. Puede ser beneficioso en casos en los que el código no se puede corregir (porque está controlado por un tercero), como medida de prevención de emergencia mientras se aplican medidas más completas de aseguramiento del software, o para proporcionar defensa en profundidad [REF-1481].
• Arquitectura y diseño, Operación: Ejecute su código utilizando los privilegios más bajos que se requieran para llevar a cabo las tareas necesarias [REF-76]. Si es posible, cree cuentas aisladas con privilegios limitados que se usen únicamente para una sola tarea. De esa manera, un ataque exitoso no dará de inmediato al atacante acceso al resto del software o de su entorno. Por ejemplo, las aplicac