Las vulnerabilidades de tipo file inclusion permiten que un atacante cargue archivos no autorizados en una aplicación web, ya sea desde el mismo servidor o desde una ubicación remota. Entender cómo funcionan LFI (Local File Inclusion) y RFI (Remote File Inclusion) es clave para cualquier persona que quiera adentrarse en seguridad web ofensiva, especialmente si trabajas con entornos PHP o auditas aplicaciones legacy.

¿Qué es Local File Inclusion (LFI) y cómo se explota?

LFI ocurre cuando una aplicación web acepta como parámetro la ruta de un archivo local sin validar correctamente su origen. En DVWA, dentro de la sección file inclusion, encuentras un parámetro page en la URL que carga archivos como include.php, file1.php, file2.php y file3.php [00:38].

La prueba inicial es sencilla: si escribes manualmente file4.php aunque no esté listado, la aplicación lo carga igual. Eso ya es una inclusión no autorizada [01:33]. A partir de ahí puedes escalar el ataque usando path traversal con ../ para retroceder directorios.

¿Qué hace la secuencia ../ en una URL? Cada ../ te mueve un nivel de carpeta hacia atrás. Si encadenas varias, llegas a la raíz del sistema y desde ahí puedes acceder a rutas como /etc/passwd para listar usuarios.

¿Qué archivos sensibles puedes leer con LFI?

En la demo, tras encadenar cinco veces ../ y apuntar a etc/passwd, se obtiene la lista de usuarios del sistema: root, games, uucp, list manager, nobody, klog, bin, administrator, proftpd, entre otros [02:14]. Si el servidor corriera como root, también podrías leer /etc/shadow, donde se almacenan los hashes de contraseñas.

Más allá de leer credenciales, LFI abre la puerta a vectores avanzados:

• Lectura de access logs de Apache para inyectar payloads.
• Lectura de logs del sistema en general.
• Acceso a /proc/self/environ, que en escenarios avanzados permite inyectar código y obtener una web shell.

Estos vectores combinan inclusión con inyección, y son la antesala de una ejecución remota de comandos.

¿Qué es Remote File Inclusion (RFI) y por qué es más peligroso?

RFI permite cargar archivos que no están en el servidor objetivo, sino en una ubicación externa controlada por el atacante. En la demostración, al pasar https://www.youtube.com como valor del parámetro page, la aplicación renderiza el index de YouTube dentro del propio servidor vulnerable [03:54].

Esto parece inofensivo cuando cargas una página pública, pero el escenario cambia cuando el archivo remoto es malicioso.

¿Por qué cargar un archivo PHP desde FTP es peligroso? Porque el protocolo FTP no procesa PHP, devuelve el archivo en texto plano. La aplicación vulnerable sí lo interpreta y lo ejecuta, lo que permite al atacante subir una web shell y ejecutar comandos en el servidor.

El flujo típico de explotación RFI consiste en alojar un script PHP en un servidor controlado (HTTP o FTP), pasar su URL como parámetro y dejar que la aplicación objetivo lo descargue e interprete. A partir de ahí, el atacante puede mantener persistencia, pivotar a otros servicios o exfiltrar datos.

¿Cuál es la diferencia clave entre LFI y RFI?

Ambas vulnerabilidades comparten la raíz: inclusión de archivos sin validar el input del usuario. La diferencia está en el origen del archivo y en el alcance del ataque.

• LFI: incluye archivos que ya existen en el servidor. Útil para leer configuraciones, credenciales o logs.
• RFI: incluye archivos alojados en servidores externos. Permite ejecutar código arbitrario desde el primer momento.
• Vector común: parámetros tipo page= o file= que aceptan rutas sin filtrar.

¿Qué es una web shell? Es un script que el atacante sube al servidor para ejecutar comandos del sistema operativo a través del navegador, como si tuviera una terminal remota.

¿Cómo se previenen estas vulnerabilidades en aplicaciones web?

La mitigación pasa por nunca confiar en el input del usuario para construir rutas de archivo. Algunas prácticas concretas:

• Usar whitelists de archivos permitidos en lugar de aceptar cualquier valor.
• Desactivar allow_url_include en la configuración de PHP para bloquear RFI.
• Validar y sanitizar parámetros que terminen en include, require o funciones similares.
• Configurar el archivo .htaccess para ocultar y proteger rutas sensibles.

DVWA es un laboratorio ideal para practicar estos conceptos en niveles low, medium y high, y observar cómo cada capa de validación cierra vectores de ataque.

Si te interesa profundizar en explotación avanzada con /proc/self/environ, web shells vía FTP o técnicas de evasión de filtros, déjalo en los comentarios.