El problema de los "Server Side Includes" en un servidor web

SSI es el acrónimo de "Server Side Include" y se trata de un mecanismo (en desuso) que permite a un servidor web añadir contenido dinámico a los documentos que sirve. Actualmente encontrar sitios que hagan uso de ésta característica no es muy habitual y los pocos que lo hacen es probablemente como consecuencia de herencias de antiguos desarrollos. Sin embargo, en ocasiones es posible encontrar sitios que todavía lo implementen, por lo que aún puede resultar interesante saber cómo funciona.

Este es un ejemplo simple y práctico de en qué consistiría una inclusión de otro fichero mediante SSI. Por ejemplo, la inclusión se realizaría mediante este código:

Inclusión del fichero content.txt mediante SSI

Lo que parece un comentario HTML se trata sin embargo de una directiva de "Server Side Include". El servidor la reemplazará por el contenido del fichero "content.txt" y se enviará al cliente una respuesta final como la mostrada en la siguiente captura de pantalla.

Respuesta del servidor web
La configuración

Para hacer uso de la característica de ‘Server Side Include’ en un servidor web, es necesario configurarlo adecuadamente además de introducir una directiva SSI en el documento que se vaya a visualizar. La configuración para los dos servidores web más utilizados (Apache e Internet Information Services), es tan sencilla como añadir la siguiente directiva al fichero de configuración de Apache o en un fichero .htaccess.


En IIS, sin embargo, es necesario activar la característica localizada en "Internet Information Services > World Wide Web Services > Application Development Features > Server-Side Includes".

Configuración de SSI en IIS
Una vez activada la característica, es necesario habilitar el manejador del módulo desde "Handler Mappings > Add Module Mapping".

Configuración de SSI en IIS
Las directivas

Una vez habilitado, únicamente será necesario introducir en el documento a servir una directiva que sea reconocida por el servidor web. No existe un estándar en cuanto a éstas directivas, por lo que cada servidor web implementa las que considera oportunas. Esto genera grandes diferencias y matices a la hora de implementar directivas entre los distintos servidores web. En estas páginas se puede encontrar la documentación oficial de las directivas permitidas en Apache e IIS.

Una de las directivas más interesantes es "exec". Permite la ejecución de comandos en el servidor. Una sintaxis correcta para esta directiva podría ser la siguiente,

< !-- #exec cmd="dir" -- >

Sin embargo, al tratarse "exec" de una directiva potencialmente peligrosa (debido a que ejecuta comandos directamente en el servidor) viene deshabilitada de forma predeterminada, por lo que es necesario realizar unas configuraciones extra para su ejecución.

El problema

Otra característica curiosa en cuanto a los "Server Side Includes" es que, en determinados entornos, son procesados después del resto de manejadores. Supongamos que disponemos de un servidor web que tiene instalado el módulo de PHP y además tiene habilitado los "Server Side Includes". Si el flujo de ejecución de una petición pasa primero por el motor de PHP y posteriormente por el de SSI, nos encontramos potencialmente ante un fallo de seguridad.


En resumen, si un usuario pudiese alterar la salida generada por el módulo de PHP, esta salida se convertiría en la entrada directa del módulo de SSI. De este modo, si un usuario es capaz de generar en la salida de ejecución de PHP algo que contenga una directiva SSI, esta sería la entrada directa para el módulo de ‘Server Side Include’ y por lo tanto se podrían "crear directivas" al vuelo gracias a PHP.

Con una representación gráfica muy simplificada, este sería el flujo con entradas y salidas de ejecución de los manejadores, así como la salida final la cual es enviada al cliente final.
Flujo de ejecución
El vector de explotación contra la arquitectura se basa fundamentalmente en las capas inferiores que son ejecutadas antes que el SSI. Por ejemplo, en el esquema mostrado con PHP, se perseguiría que el módulo de PHP muestre una directiva SSI en su salida. Esto puede conseguirse por ejemplo mediante ataques de "Cross Site Scripting" (XSS). A continuación se muestra un ejemplo de esta vulnerabilidad encontrada mediante el servicio de pentesting persistente Faast.


Explotando una vulnerabilidad SSI
El proceso de detección en este ejemplo consiste en la creación de una variable llamada "faastvar" con la cadena "FA$ST" como contenido. Posteriormente ésta variable es mostrada mediante otra directiva "echo".

Manuel Fernández

manuel.fernandez@11paths.com