Glosario
Qué es el path traversal (recorrido de rutas): leer archivos que el servidor nunca debería servir, mediante ../
El path traversal (recorrido de directorios) mezcla ../ en un nombre de archivo para leer o escribir archivos fuera de la carpeta prevista: .env, claves, /etc. Cómo funciona y la defensa real: no usar la entrada como ruta y confinarla a una base.
«Pon ../ en el campo de nombre de archivo y el .env profundo del servidor se vuelve legible»: eso es el path traversal. Aquí tienes cómo funciona y cómo prevenirlo de forma fiable (sin pasos de ataque).
Dónde aparece
En cualquier sitio donde «la entrada del usuario elige un archivo».
| Función | El uso peligroso |
|---|---|
| Descarga / vista previa | Usar ?file= directamente como nombre de archivo |
| Mostrar imágenes / adjuntos | Construir parte de la ruta a partir de un parámetro de URL |
| Subida | Usar un nombre proporcionado por el usuario en la ruta de guardado (tipo escritura, el más peligroso) |
| Carga de plantillas / idiomas | Elegir un archivo dinámicamente mediante ?lang=, etc. |
Por qué funciona
../ significa «subir un nivel». Si la aplicación concatena carpeta pública + entrada del usuario y abre ese archivo, los segmentos ../ apilados dejan que la solicitud «camine» fuera de la carpeta pública.
Leer significa divulgación; escribir (subidas) significa archivos plantados en cualquier sitio, lo que puede llevar a RCE.
Defensa: no uses la entrada como ruta + confina a la base
Nunca uses la entrada del usuario como ruta de archivo en bruto (lo más importante)
Resuelve los archivos expuestos mediante una lista de permitidos ID → archivo real. El usuario pasa solo un identificador («3», «factura»); el servidor decide la ruta real.
Normaliza y luego verifica que queda dentro del directorio base
Conviértela en una ruta absoluta con el resolutor del lenguaje (resolve/realpath) y comprueba que empieza por el directorio base permitido. Rechaza todo lo que quede fuera. La eliminación ingenua de la cadena '../' falla ante las elusiones por codificación.
Ejecuta la aplicación con privilegios mínimos
Limita qué archivos puede leer el usuario de ejecución de la aplicación a lo que la tarea necesite. Aunque alguien escape, los archivos ilegibles no filtran nada.
Mantén los secretos completamente fuera de la raíz pública
No coloques .env, .git, claves ni copias de seguridad en la raíz web o en la carpeta de subidas para empezar. Elimina la superficie de ataque mediante la ubicación.
La visión de este sitio: es continuo con los errores de ubicación; corrige en el orden correcto
El path traversal es continuo con el incidente de exposición de .env: ambos son «algo que nunca debería ser alcanzable por la web se vuelve alcanzable por la web». El parche (cabeceras, filtros ingenuos) oculta el síntoma; si el código y la ubicación no se corrigen, otra vía sigue filtrando. El orden es (1) código que no usa la entrada como ruta, (2) confinamiento al directorio base, (3) mantener los secretos fuera de la raíz pública. Lee ubicación segura en hosting compartido junto a esto para ver la forma de la solución real.
Sigue leyendo
- Incidente: Exponer el archivo .env completo
- Defensa: Proteger .env en hosting compartido · Glosario: Qué es RCE
FAQ
Q¿Qué se filtra en un path traversal?
Archivos que la aplicación nunca debía exponer: .env (credenciales de la base de datos, claves de API), archivos de configuración, claves privadas, código fuente, rutas del sistema operativo como /etc. Más allá de leer, si alcanza la ruta de destino de una subida, puede escribir en cualquier sitio y escalar a RCE (ejecución remota de código).
Q¿Cuál es la mejor defensa?
Nunca uses la entrada del usuario como ruta de archivo en bruto. Si debes hacerlo, mapéala a través de una lista de permitidos (un conjunto fijo de IDs/nombres de archivo), normaliza la ruta con una librería y verifica que el resultado queda dentro del directorio base permitido. Las comprobaciones de extensión o la eliminación ingenua de '../' se eluden.
Q¿Puedo bloquearlo simplemente con .htaccess o cabeceras?
Eso es un parche para un problema distinto (archivos sensibles ubicados en la raíz web). La solución de raíz es colocar el cuerpo de la aplicación, .env y .git FUERA de la raíz pública, además de código que no use la entrada como ruta. El parche y la solución real son tareas separadas.