Vulnerabilidades Avanzadas en Aplicaciones Web

Como ya he explicado muchas veces qué es un XSS, SQLi y similares, hoy paso a algo más avanzado, que ya entra en un terreno más técnico y menos obvio para el usuario medio. Vamos a tocar SSRF, CSRF, problemas con plantillas inseguras (SSTI), DWR y otras cosillas que, si te las cruzas, pueden darte acceso a sitios donde ni el admin debería meterse sin pensarlo dos veces.

SSRF (Server-Side Request Forgery)

Permite que un atacante haga que el servidor haga peticiones HTTP donde no debería. Esto es como usar el servidor como proxy para llegar a sitios internos o servicios que desde fuera están cerrados.

• Ejemplo de payload básico: http://victima.com/fetch?url=http://127.0.0.1:8080/admin
• Se usa para acceder a paneles internos, leer metadatos de la nube (http://169.254.169.254/latest/meta-data/), o incluso lanzar ataques contra otros sistemas desde dentro.
• Mitigación: lista blanca estricta, rechazar IPs privadas, sanitizar URLs y usar timeouts.

CSRF (Cross-Site Request Forgery)

Este no ataca al servidor directamente, sino que engaña al navegador de una víctima autenticada para que haga peticiones que ella no quería hacer.

• Un clásico: el usuario abre un enlace malicioso y sin darse cuenta hace un POST que cambia su email o contraseña.
• Se arregla usando tokens únicos por sesión (CSRF tokens), y verificando origen (Origin, Referer).

SSTI (Server-Side Template Injection)

Cuando los datos de usuario se insertan directamente en plantillas sin validación, y el motor de plantillas permite ejecución de código.

• Ejemplo con Jinja2: {{7*7}} devuelve 49 si es vulnerable.
• Puedes llegar a ejecutar código en el servidor si consigues abusar de objetos y métodos internos.
• Prevención: no meter datos directos, escapar siempre, usar autoescape y entornos restringidos.

DWR (Direct Web Remoting)

Es una librería Java que expone métodos del lado servidor para que el cliente los llame como si fueran JavaScript. Muy cómodo para devs, pero si no está bien configurado, es como dejar la puerta de atrás abierta.

• Ejemplo de rutas que pueden aparecer: /dwr/call/plaincall/UsuarioService.getUsuario.dwr /dwr/call/plaincall/AdminService.getConfig.dwr
• Si está mal asegurado, podrías:
  • Llamar métodos internos que no deberían ser accesibles.
  • Exfiltrar datos como listas de usuarios, configs, etc.
  • Incluso ejecutar acciones administrativas si no hay controles.
• Mitigación: limitar métodos expuestos, filtrar por roles, desactivar DWR si no se usa.

Otros vectores menos hablados

• Open Redirect: si dejas que el usuario elija a dónde redirigir, puedes ser usado en phishing. Ejemplo: /redir?url=http://phish.com
• Path Traversal: abusar de ../ para leer ficheros fuera de la carpeta prevista. Ejemplo: /view?file=../../etc/passwd
• Deserialización insegura: enviar objetos maliciosos que, al deserializar, ejecutan código.
• Header Injection: inyectar cabeceras personalizadas que alteran la respuesta.
• HTTP Parameter Pollution: mandar parámetros duplicados para alterar el comportamiento de una petición.

Payloads de prueba recomendados

Si quieres saber si algo está mal, prueba cosas como:

• {{7*7}} o ${7*7} para SSTI
• ../../etc/passwd para path traversal
• javascript:alert(1) en campos de URL
• Parámetros duplicados tipo ?id=1&id=2