Unirme a CiberInsider

Server Side Template Injection (SSTI): qué es y cómo funciona

Índice

4 llaves ({{}}) pueden darle a un hacker el control total de un servidor.

Suena absduro, ¿verdad? Pero eso es exactamente lo que puede ocurrir con la vulnerabilidad Server-side template injection.

Solo hace falta una línea, una expresión inofensiva en apariencia, y el servidor hará exactamente lo que el atacante le pida. Desde resolver una operación matemática hasta ejecutar un comando a nivel del sistema.

En este artículo, te explicaré qué es, cómo funciona y aprenderás a explotarla en un laboratorio práctico.

¿Qué es el SSTI o Server-side template injection?

Server-Side Template Injection (SSTI) es una vulnerabilidad que ocurre cuando una aplicación web permite que la entrada de un usuario se inserte de forma insegura dentro de una plantilla que será procesada en el servidor. Esto significa que, en lugar de tratar el dato como texto, el servidor lo interpreta como código.

Para que puedas entenderme:

Imagina que estás en una red social y puedes editar tu biografía. En el backend, el desarrollador usa una plantilla para mostrar tu perfil. Ahora tú como usuario, escribes tu biografía. Hasta ahí, todo bien.

El servidor remplaza la plantilla por el texto que tu has introducido en tu biografía.

Si el servidor, no gestiona correctamente la entrada del usuario, este, puede ser tratado como código en vez de texto.

¿Resultado? Dile adiós a tus datos.

Esta vulnerabilidad no depende de un lenguaje en particular. Aunque es muy común en entornos Python con motores de plantillas como Jinja2 (usado en Flask o Django), lo que tienen en común todos estos entornos es que usan plantillas para construir contenido dinámico.

¿Cómo funciona el SSTI?

Vale, pero cómo funciona realmente esta vulnerabilidad.

Vamos a lo esencial: las plantillas son archivos que combinan contenido estático con partes dinámicas. Un ejemplo clásico sería:

<p>Hola, {{ username }}</p>

Aquí, el valor de username se reemplaza en tiempo real por el nombre del usuario. Esto es completamente seguro… siempre que ese valor venga del servidor, no del usuario.

El problema surge cuando el contenido dinámico es controlado por el usuario y se evalúa dentro de la plantilla. Imagina que alguien escribe esto en un formulario:

{{ 7 * 7 }}

Y la aplicación, sin filtros, responde con:


49

Eso significa que el motor de plantillas está evaluando expresiones del usuario. Y si puede hacer eso… puede hacer mucho más. Por ejemplo, acceder a funciones internas del sistema, mostrar archivos del servidor o ejecutar comandos.

¿Cómo lo logran los atacantes? A través de técnicas como el encadenamiento de objetos (object traversal), acceso a clases base, y uso de lo que se conoce como gadgets: fragmentos de código ya disponibles en la aplicación o en bibliotecas del lenguaje, que se pueden aprovechar para ejecutar instrucciones maliciosas.

Ejemplo real de SSTI

He visto esta vulnerabilidad tanto, durante la preparación de certificaciones como el eCPPTv2 o el eWPTXv2, como también en un caso real.

En una auditoría, me encontré con una funcionalidad que generaba PDFs personalizados a partir de datos que el usuario podía introducir. Lo interesante es que esos datos se procesaban como plantillas, y se renderizaban en tiempo real dentro del PDF.

Decidí probar una expresión como {{ 7 * 7 }}… y la respuesta fue “49”. Eso confirmó que el motor de plantillas estaba ejecutando código en el servidor.

Aunque no llegué a escalarlo a una ejecución remota de comandos (RCE), sí pude confirmar que existía una SSTI: el servidor evaluaba expresiones, y eso me daba cierto grado de interacción con el entorno.

Algo que me ayuda a averiguar si existe un SSTI, es entender cómo la aplicación genera la información que vemos por pantalla. Ya sea en un PDF, tu biografía o tu nombre de usuario.

Impacto de la vulnerabilidad SSTI

El impacto de una SSTI, como siempre, depende del contexto y del alcance, pero normalmente suele ser alto o incluso crítico. No estamos hablando solo de inyectar texto o alterar el diseño de una página; estamos hablando de un posible acceso completo al servidor.

Algunas consecuencias posibles son:

  • Ejecución remota de comandos (RCE): el atacante puede ejecutar código a nivel de sistema.
  • Exfiltración de información sensible: Mostrar contenido crítico del sistema como contraseñas.
  • Persistencia: puede instalar backdoors o herramientas de administración remota.
  • Movimiento lateral: si el servidor comprometido tiene acceso a otras partes de la infraestructura, el atacante puede avanzar y comprometer más sistemas.

Ahora que ya conoces cómo funciona la vulnerabilidad, vamos a realizar un laboratorio práctico:

Únete a CiberInsider y  prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Clase gratuita ciberseguridad
CLASE GRATUITA
Descubre cómo conseguir tu primer trabajo en ciberseguridad para asegurar tu futuro profesional en un sector en pleno crecimiento y con muy buen salario