File Inclusion

Muchos lenguajes de back-end modernos, como PHP, Javascripto Java, utilizan parámetros HTTP para especificar lo que se muestra en la página web, lo que permite crear páginas web dinámicas, reduce el tamaño del script y simplifica el código. En estos casos, se utilizan parámetros para especificar qué recurso se muestra en la página. Si estas funcionalidades no están codificadas de forma segura, un atacante podría manipularlos para mostrar el contenido de cualquier archivo local en el servidor, lo que genera una vulnerabilidad de inclusión de archivos locales (LFI) .

Inclusión de archivos locales (LFI)

El lugar más común donde encontramos LFI es en los motores de plantillas. Para que la mayor parte de la aplicación web se vea igual al navegar entre páginas, un motor de plantillas muestra una página con las partes estáticas comunes, como header, navigation bary footer, y luego carga dinámicamente el resto del contenido que cambia entre páginas. De lo contrario, cada página del servidor tendría que modificarse al realizar cambios en cualquiera de las partes estáticas. Por eso, a menudo vemos un parámetro como /index.php?page=about, donde index.phpestablece contenido estático (p. ej., encabezado/pie de página) y luego solo extrae el contenido dinámico especificado en el parámetro, que en este caso puede leerse desde un archivo llamado about.php. Como tenemos control sobre la aboutparte de la solicitud, es posible que la aplicación web tome otros archivos y los muestre en la página.

Las vulnerabilidades de LFI pueden provocar la divulgación del código fuente, la exposición de datos confidenciales e incluso la ejecución remota de código en determinadas circunstancias. La filtración de código fuente puede permitir a los atacantes probar el código en busca de otras vulnerabilidades, lo que podría revelar vulnerabilidades previamente desconocidas. Además, la filtración de datos confidenciales puede permitir a los atacantes enumerar el servidor remoto en busca de otras debilidades o incluso filtrar credenciales y claves que les permitan acceder directamente a él. En determinadas circunstancias, LFI también puede permitir a los atacantes ejecutar código en el servidor remoto, lo que puede comprometer todo el servidor back-end y cualquier otro servidor conectado a él.

Ejemplos de código vulnerable

Analicemos algunos ejemplos de código vulnerable a la inclusión de archivos para comprender cómo se producen. Como se mencionó anteriormente, las vulnerabilidades de inclusión de archivos pueden ocurrir en muchos de los servidores web y frameworks de desarrollo más populares, como [ PHPnombre del servidor], NodeJS[ nombre del servidor Java], [ .Netnombre del servidor] y muchos otros. Cada uno de ellos utiliza un enfoque ligeramente diferente para incluir archivos locales, pero todos comparten una característica común: cargar un archivo desde una ruta específica.

Dicho archivo podría ser un encabezado dinámico o contenido diferente según el idioma especificado por el usuario. Por ejemplo, la página puede tener un ?languageparámetro GET y, si un usuario cambia el idioma desde un menú desplegable, se devolvería la misma página, pero con un languageparámetro diferente (p. ej., ?language=es). En tales casos, cambiar el idioma puede cambiar el directorio desde el que la aplicación web carga las páginas (p. ej. /en/, o /es/). Si controlamos la ruta de carga, podríamos explotar esta vulnerabilidad para leer otros archivos y, potencialmente, permitir la ejecución remota de código.

PHP

En [nombre del archivo PHP], podemos usar la include()función para cargar un archivo local o remoto al cargar una página. Si el valor pathpasado a [ nombre del archivo include()] se toma de un parámetro controlado por el usuario, como un GETparámetro [nombre del archivo] y the code does not explicitly filter and sanitize the user input[nombre del archivo], el código se vuelve vulnerable a la inclusión de archivos. El siguiente fragmento de código muestra un ejemplo:

if (isset($_GET['language'])) {
    include($_GET['language']);
}

Vemos que el languageparámetro se pasa directamente a la include()función. Por lo tanto, cualquier ruta que pasemos en el languageparámetro se cargará en la página, incluyendo cualquier archivo local en el servidor backend. Esto no es exclusivo de la include()función, ya que existen muchas otras funciones PHP que podrían causar la misma vulnerabilidad si tuviéramos control sobre la ruta que se les pasa. Entre estas funciones se incluyen include_once(), require(), require_once(), file_get_contents(), y muchas otras.

NodeJS

Al igual que con PHP, los servidores web NodeJS también pueden cargar contenido basándose en parámetros HTTP. El siguiente es un ejemplo básico de cómo languagese usa un parámetro GET para controlar los datos que se escriben en una página:

if(req.query.language) {
    fs.readFile(path.join(__dirname, req.query.language), function (err, data) {
        res.write(data);
    });
}

Como podemos ver, cualquier parámetro pasado desde la URL es utilizado por la readfilefunción, que luego escribe el contenido del archivo en la respuesta HTTP. Otro ejemplo es la render()función en el Express.jsframework. El siguiente ejemplo muestra cómo languagese utiliza el parámetro para determinar el directorio about.htmldel que se extrae la página:

app.get("/about/:language", function(req, res) {
    res.render(`/${req.params.language}/about.html`);
});

A diferencia de nuestros ejemplos anteriores, donde los parámetros GET se especificaban después de un ?carácter ( ) en la URL, el ejemplo anterior toma el parámetro de la ruta URL (por ejemplo, /about/eno /about/es). Como el parámetro se usa directamente dentro de la render()función para especificar el archivo renderizado, podemos cambiar la URL para mostrar un archivo diferente.

Java

El mismo concepto se aplica a muchos otros servidores web. Los siguientes ejemplos muestran cómo las aplicaciones web para un servidor web Java pueden incluir archivos locales según el parámetro especificado, mediante la includefunción:

<c:if test="${not empty param.language}">
    <jsp:include file="<%= request.getParameter('language') %>" />
</c:if>

La includefunción puede tomar la URL de un archivo o una página como argumento y luego renderizar el objeto en la plantilla frontend, de forma similar a lo que vimos anteriormente con NodeJS. La importfunción también puede usarse para renderizar un archivo local o una URL, como en el siguiente ejemplo:

<c:import url= "<%= request.getParameter('language') %>"/>

.Net

Finalmente, veamos un ejemplo de cómo pueden ocurrir vulnerabilidades de inclusión de archivos en aplicaciones web .NET. La Response.WriteFilefunción funciona de forma muy similar a todos los ejemplos anteriores, ya que toma una ruta de archivo como entrada y escribe su contenido en la respuesta. La ruta puede obtenerse de un parámetro GET para la carga dinámica de contenido, como se indica a continuación:

@if (!string.IsNullOrEmpty(HttpContext.Request.Query['language'])) {
    <% Response.WriteFile("<% HttpContext.Request.Query['language'] %>"); %> 
}

Además, la @Html.Partial()función también se puede utilizar para representar el archivo especificado como parte de la plantilla del frontend, de manera similar a lo que vimos anteriormente:

@Html.Partial(HttpContext.Request.Query['language'])

Finalmente, la includefunción se puede utilizar para renderizar archivos locales o URL remotas, y también puede ejecutar los archivos especificados:

<!--#include file="<% HttpContext.Request.Query['language'] %>"-->

Leer vs Ejecutar

De todos los ejemplos anteriores, podemos ver que las vulnerabilidades de inclusión de archivos pueden ocurrir en cualquier servidor web y en cualquier marco de desarrollo, ya que todos ellos proporcionan funcionalidades para cargar contenido dinámico y manejar plantillas front-end.

Lo más importante a tener en cuenta es que some of the above functions only read the content of the specified files, while others also execute the specified filesalgunos permiten especificar URL remotas, mientras que otros solo funcionan con archivos locales del servidor backend.