🛡️ Guía independiente de formación en ciberseguridad · Certificaciones, itinerarios y cursos
Inicio › Cursos › Curso de Hacking Web: Pentesting de Aplicaciones Web desde Cero
Módulo 6 de 10

Módulo 6: CSRF y SSRF

Módulo 6: CSRF y SSRF

Aviso legal y ético obligatorio (España): Todo el contenido de este módulo tiene finalidad educativa y defensiva. La explotación de vulnerabilidades en sistemas ajenos sin autorización explícita y por escrito constituye un delito tipificado en el artículo 197 bis del Código Penal español, con penas de prisión de seis meses a dos años. Practica exclusivamente en entornos de laboratorio que controles: DVWA, OWASP Juice Shop, PortSwigger Web Security Academy o máquinas virtuales propias. Ninguna técnica de este módulo debe aplicarse fuera de esos entornos sin permiso explícito.

Módulo 6: CSRF y SSRF — Forjado de peticiones desde el cliente y desde el servidor

Este módulo cubre dos vulnerabilidades que comparten el apellido «forgery» (falsificación) pero atacan planos completamente distintos: CSRF fuerza al navegador del usuario a enviar peticiones no autorizadas, mientras que SSRF fuerza al servidor de la aplicación a realizar peticiones hacia recursos internos o externos. Comprender ambas es fundamental tanto para quien audita aplicaciones web como para quien las construye.

El encuadre de ambas vulnerabilidades en el OWASP Top 10:2025 (versión vigente publicada en enero de 2026) es clave para entenderlas en el contexto actual. SSRF ya no es una categoría independiente: lo que en la edición anterior figuraba como «A10:2021 — SSRF» se ha consolidado dentro de A01:2025 — Broken Access Control (control de acceso roto), que mantiene el puesto número uno del ranking. CSRF, por su parte, nunca llegó a ser categoría propia del Top 10 (apareció como A8 en 2013 y A5 en 2017) y hoy se entiende también como un fallo de control de acceso: su debilidad asociada, CWE-352, está mapeada igualmente dentro de A01:2025. En la práctica, la prevalencia de CSRF ha descendido mucho gracias a las protecciones modernas (tokens y comportamiento SameSite de los navegadores), pero sigue siendo relevante en aplicaciones legacy y en endpoints mal protegidos.

Qué aprenderás

  • Qué es CSRF, cómo funciona el ataque y cómo construir un PoC en laboratorio.
  • Las defensas reales contra CSRF: tokens sincronizados, SameSite y verificación de cabeceras.
  • Qué es SSRF, sus tipos (básico, ciego, via-redirección) y cómo se explota en lab.
  • Por qué los endpoints de metadatos cloud (169.254.169.254) son un objetivo crítico.
  • Cómo prevenir SSRF con allowlists, segmentación de red y restricción de esquemas.
  • Dónde practicar de forma legal y gratuita: PortSwigger Web Security Academy y DVWA.

Parte A — CSRF: Cross-Site Request Forgery

¿Qué es CSRF?

CSRF (Cross-Site Request Forgery, también conocido como XSRF o «sea-surf») es un ataque en el que un sitio malicioso engaña al navegador de una víctima autenticada para que envíe una petición HTTP no deseada a otra aplicación web en la que la víctima tiene una sesión activa. El servidor receptor recibe la petición junto con las cookies de sesión legítimas del usuario y la ejecuta como si fuera voluntaria.

La vulnerabilidad existe porque los navegadores incluyen automáticamente las cookies de dominio en cualquier petición hacia ese dominio, independientemente del origen que inicie la petición. Si la aplicación destino valida la identidad del usuario únicamente por su cookie de sesión, no tiene manera de distinguir entre una petición legítima y una forjada.

Según la documentación de PortSwigger Web Security Academy, para que un ataque CSRF tenga éxito deben cumplirse tres condiciones:

  1. Acción relevante: existe una acción en la aplicación que el atacante quiere provocar (cambio de email, transferencia de fondos, modificación de contraseña, etc.).
  2. Manejo de sesión basado solo en cookies: la aplicación identifica al usuario únicamente mediante cookies de sesión sin ningún parámetro adicional imposible de predecir.
  3. Parámetros predecibles: la petición no contiene valores que el atacante no pueda conocer o adivinar de antemano (como un token secreto aleatorio).

Construyendo un PoC en laboratorio

El laboratorio recomendado es PortSwigger Web Security Academy — CSRF. La Academy ofrece decenas de labs gratuitos con entornos preconfigurados.

Escenario de laboratorio: cambio de email sin protección CSRF

Supón que en el laboratorio existe un formulario que permite al usuario autenticado cambiar su dirección de email. La petición legítima es:

POST /my-account/change-email HTTP/1.1
Host: vulnerable-lab.web-security-academy.net
Cookie: session=AbCdEfGhIj1234567890
Content-Type: application/x-www-form-urlencoded

email=victima%40legit.com

El atacante observa que no hay ningún token CSRF. Construye la siguiente página en su servidor bajo control:

<!-- PoC CSRF — solo en laboratorio autorizado -->
<html>
  <body onload="document.forms[0].submit()">
    <form method="POST"
          action="https://vulnerable-lab.web-security-academy.net/my-account/change-email">
      <input type="hidden" name="email" value="atacante@evil.com">
    </form>
  </body>
</html>

Cuando la víctima (autenticada en el laboratorio) visita esta página, su navegador envía automáticamente la petición POST incluyendo la cookie de sesión. El servidor la procesa y cambia el email sin que el usuario lo haya solicitado. El atacante puede entonces usar la función «recuperar contraseña» para tomar el control de la cuenta.

CSRF contra peticiones GET (más sencillo)

Si la acción sensible se ejecuta con un método GET, el ataque es aún más trivial. Basta con una etiqueta imagen:

<img src="https://lab-banco.example/transfer?to=atacante&amount=1000"
     width="0" height="0">

El navegador cargará la imagen (con las cookies) y ejecutará la transferencia. Esta es la razón por la que las acciones que modifican estado nunca deben implementarse con GET.

Impacto de CSRF

El impacto depende de qué acción se puede forzar:

  • Cambio de email o contraseña → toma de cuenta completa.
  • Transferencias o compras → pérdida económica directa.
  • Si la víctima es administrador → compromiso total de la aplicación.
  • Publicación de contenido no autorizado (foros, redes sociales, CMS).

Prevención de CSRF

1. Tokens anti-CSRF sincronizados (Synchronizer Token Pattern)

Es la defensa principal recomendada por la OWASP CSRF Prevention Cheat Sheet. El servidor genera un token criptográficamente aleatorio y único por sesión (o por formulario), lo incluye en el HTML del formulario como campo oculto, y lo valida al recibir la petición.

<!-- En el formulario HTML del servidor -->
<form method="POST" action="/change-email">
  <input type="hidden" name="csrf_token"
         value="a8f3b2e1c4d9f0a7b6e2d5c3a1f8b4e7">
  <input type="email" name="email">
  <button type="submit">Guardar</button>
</form>

El atacante no puede incluir un token válido en su PoC porque no tiene acceso al DOM de la aplicación destino (bloqueado por la política Same-Origin). La validación en el servidor debe rechazar cualquier petición con token ausente, vacío o incorrecto.

Requisitos del token: entropía mínima de 128 bits, generado con CSPRNG (no Math.random()), almacenado en sesión del lado servidor, invalidado al cerrar sesión.

El Synchronizer Token Pattern requiere estado en servidor. Para arquitecturas stateless, la OWASP CSRF Prevention Cheat Sheet recomienda en 2026 el patrón Signed Double-Submit Cookie: el token se firma con HMAC vinculándolo a la sesión del usuario, de modo que no pueda falsificarse. El doble envío «ingenuo» (comparar sin más una cookie con un campo del formulario) está desaconsejado, porque es vulnerable a inyección de cookies desde subdominios. La regla práctica: usa el token sincronizado si tu framework mantiene sesión en servidor, y el doble envío firmado si necesitas no guardar estado. Lo prioritario es que CUALQUIER petición que cambie estado lleve y valide un token anti-CSRF.

2. Atributo SameSite en cookies

El atributo SameSite controla si el navegador envía las cookies en peticiones cross-site. Desde Chrome 80 (2020) los navegadores basados en Chromium (Chrome, Edge, Opera) tratan como SameSite=Lax las cookies que no declaran explícitamente el atributo, y en 2026 ese sigue siendo su comportamiento por defecto. Atención: este «Lax por defecto» no es universal. Firefox y Safari no aplican Lax por defecto; en su lugar limitan las cookies de terceros mediante particionado (Total Cookie Protection) e Intelligent Tracking Prevention respectivamente. La conclusión defensiva es que nunca debes confiar en el valor por defecto del navegador: declara siempre SameSite de forma explícita en tus cookies de sesión.

Valor Comportamiento Protección CSRF
Strict Cookie no se envía en ninguna petición cross-site Máxima
Lax Solo se envía en navegación top-level GET Alta (cubre POST, iframe, img)
None Se envía siempre (requiere Secure) Ninguna 
Set-Cookie: session=TOKEN; SameSite=Strict; Secure; HttpOnly; Path=/

Importante: SameSite no debe ser la única defensa. PortSwigger documenta varios métodos de bypass de SameSite: method override (camuflar un POST como GET), redirecciones del lado cliente desde un origen hermano, y la ventana de 120 segundos que Chromium concede a las cookies sin atributo explícito. Sobre esta última conviene ser preciso: para no romper flujos de inicio de sesión (SSO/OAuth), Chromium no aplica la restricción Lax durante los primeros 120 segundos de vida de una cookie en peticiones POST top-level; un atacante puede forzar la reemisión de la cookie (p. ej. mediante un flujo OAuth) para «reiniciar» ese contador. Este margen solo afecta a cookies que NO declaran SameSite — no se aplica a cookies fijadas explícitamente con SameSite=Lax, otra razón para declarar siempre el atributo. Úsalo como defensa en profundidad junto con tokens.

3. Verificación de cabeceras Origin y Referer

El servidor puede verificar que la cabecera Origin (siempre presente en peticiones POST cross-origin) o Referer coincide con el dominio propio. Es una capa adicional, no un sustituto del token:

# Pseudocódigo de validación en servidor
origin = request.headers.get("Origin")
if origin and origin != "https://miapp.com":
    return 403  # Rechazar petición cross-origin

Casos a considerar: la cabecera Referer puede estar ausente (navegación directa, noreferrer), por lo que la lógica debe manejar la ausencia de forma segura (generalmente: rechazar si se exige, o aceptar si la política lo permite solo cuando Origin también falta).

Resumen defensa CSRF: tokens sincronizados (obligatorio) + SameSite=Strict o Lax (obligatorio) + verificación de Origin (complementario). Los tres juntos hacen el ataque prácticamente inviable.

Parte B — SSRF: Server-Side Request Forgery

¿Qué es SSRF?

SSRF (Server-Side Request Forgery) ocurre cuando una aplicación web realiza peticiones HTTP a una URL proporcionada o influenciada por el usuario sin validarla adecuadamente. El atacante consigue que sea el servidor quien realice peticiones hacia destinos arbitrarios: otros servicios internos inaccesibles desde internet, la propia máquina del servidor (localhost), o endpoints de metadatos de plataformas cloud.

Encuadre actual en OWASP (2026). SSRF había debutado como categoría propia «A10:2021» en la edición anterior del Top 10. En el OWASP Top 10:2025 ya no es una categoría independiente: se ha consolidado dentro de A01:2025 — Broken Access Control, y su debilidad asociada CWE-918 figura entre los CWE mapeados a esa categoría. Conceptualmente encaja bien ahí: SSRF es, en el fondo, lograr que el servidor acceda a recursos que el atacante no debería poder alcanzar. Su importancia no ha disminuido —al contrario, sigue creciendo con la proliferación de microservicios y entornos cloud—, solo ha cambiado su clasificación.

La definición que mantiene OWASP: las vulnerabilidades SSRF ocurren cuando una aplicación web obtiene un recurso remoto sin validar la URL suministrada por el usuario. Permiten al atacante forzar a la aplicación a enviar una petición manipulada a un destino inesperado, incluso si está protegida por un cortafuegos, VPN u otro tipo de lista de control de acceso de red.

Tipos de SSRF

SSRF básico (con respuesta visible)

El servidor realiza la petición y devuelve la respuesta directamente al atacante. Es el más fácil de explotar y detectar. Ejemplo: un servicio de «vista previa de URL» o un verificador de disponibilidad que devuelve el contenido de la URL en la respuesta HTTP.

SSRF ciego (Blind SSRF)

El servidor realiza la petición pero no devuelve la respuesta al atacante. La detección requiere técnicas fuera de banda (Out-of-Band, OAST): el atacante apunta a un servidor bajo su control (como Burp Collaborator) y confirma el SSRF observando el tráfico entrante. Según PortSwigger, blind SSRF puede encadenarse con vulnerabilidades como Shellshock para conseguir ejecución remota de código en servidores internos.

SSRF semi-ciego

El servidor no devuelve el cuerpo de la respuesta, pero sí filtra información indirectamente: códigos de error distintos, tiempos de respuesta, mensajes de excepción. Permite enumerar puertos abiertos en la red interna comparando comportamientos.

SSRF vía redirección abierta

Si el servidor sigue redirecciones HTTP (comportamiento por defecto en muchas librerías), el atacante puede encadenar una redirección abierta en el dominio permitido para llegar a destinos internos:

# Paso 1: el servidor permite peticiones a trusted.com
# Paso 2: trusted.com/redirect?url= redirige a cualquier destino
# Resultado: el servidor llega a 192.168.1.1 pasando por trusted.com
https://trusted.com/redirect?url=http://192.168.1.1/admin

Explotación a servicios internos (laboratorio)

Escenario de lab: Una aplicación tiene un endpoint /product/stock que acepta un parámetro stockApi con la URL del microservicio de inventario. En el laboratorio de PortSwigger (Basic SSRF against the local server), la petición legítima es:

POST /product/stockCheck HTTP/1.1
Host: vulnerable-lab.web-security-academy.net
Content-Type: application/x-www-form-urlencoded

stockApi=http%3A%2F%2Fstock.weliketoshop.net%3A8080%2Fproduct%2Fstock

El atacante modifica el valor para apuntar al panel de administración local, que solo es accesible desde localhost:

stockApi=http%3A%2F%2Flocalhost%2Fadmin

El servidor realiza la petición desde su propia dirección de loopback, que el panel de administración considera de confianza, y devuelve el HTML del panel administrativo en la respuesta. Desde ahí, el atacante puede enumerar usuarios y realizar acciones privilegiadas.

Explotación de metadatos cloud (SOLO EN LABORATORIO)

Advertencia explícita: la dirección 169.254.169.254 es una IP link-local que los principales proveedores cloud (AWS, Google Cloud y Azure) usan como endpoint de metadatos de la instancia. Cada proveedor tiene sus propias rutas y requisitos —por ejemplo, Azure y GCP exigen una cabecera específica (Metadata: true en Azure, Metadata-Flavor: Google en GCP)—, por lo que el ejemplo que sigue es concretamente el de AWS. Intentar acceder a este endpoint en sistemas que no sean tuyos es ilegal. Lo que sigue es descripción técnica para laboratorios autorizados como los de PortSwigger Web Security Academy.

Contexto AWS en 2026. El ataque clásico que sigue es posible cuando la instancia tiene habilitado IMDSv1 (Instance Metadata Service versión 1, sin autenticación). Hay que situarlo en su contexto actual: desde marzo de 2024 AWS exige IMDSv2 por defecto en las instancias EC2 de nueva creación, e IMDSv2 (que requiere un token de sesión obtenido por PUT) rompe la explotación SSRF simple. Sin embargo, IMDSv1 no ha sido retirado formalmente: sigue disponible y puede seguir activo en instancias antiguas o en cuentas que no han aplicado la migración ni la imposición a nivel de cuenta, por lo que continúa siendo un hallazgo real en auditorías. En un entorno (de laboratorio) con IMDSv1, un servidor vulnerable a SSRF puede filtrar credenciales IAM temporales:

# En el lab: parámetro manipulado paso a paso
# Paso 1: enumerar la raíz
stockApi=http://169.254.169.254/

# Paso 2: explorar el árbol
stockApi=http://169.254.169.254/latest/meta-data/

# Paso 3: obtener credenciales IAM
stockApi=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Paso 4: obtener el rol
stockApi=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin

La respuesta del último paso contiene AccessKeyId, SecretAccessKey y Token temporales con los permisos del rol IAM asignado a la instancia. Con estas credenciales, el atacante puede acceder a todos los recursos AWS del rol (buckets S3, funciones Lambda, bases de datos RDS, etc.).

El lab de PortSwigger que cubre este escenario vía XXE+SSRF es: Exploiting XXE to perform SSRF attacks.

Mitigación del lado cloud: IMDSv2 exige obtener primero un token de sesión mediante una petición PUT (con cabeceras que un SSRF simple no puede fijar), lo que neutraliza este vector. Como ya es el modo por defecto en instancias nuevas desde marzo de 2024, el trabajo pendiente consiste en forzar IMDSv2 en las instancias preexistentes y deshabilitar IMDSv1, idealmente imponiéndolo a nivel de cuenta para que ninguna instancia pueda arrancar con IMDSv1.

Impacto de SSRF

  • Enumeración de red interna: mapear puertos abiertos en segmentos no expuestos a internet.
  • Acceso a paneles internos: Kubernetes Dashboard, Consul, Elasticsearch, Jenkins sin autenticación interna.
  • Robo de credenciales cloud: claves IAM temporales (AWS), tokens de acceso (GCP, Azure).
  • RCE encadenado: SSRF a un servicio interno vulnerable (Redis, Memcached, Jenkins) puede derivar en ejecución remota de código.
  • Pivoting: usar el servidor comprometido como pivote para atacar otros sistemas internos.

Prevención de SSRF

La OWASP SSRF Prevention Cheat Sheet y el OWASP Top 10 Proactive Controls C10 establecen las siguientes defensas:

1. Allowlist de destinos (la defensa más sólida)

Define la lista exacta de hosts y puertos a los que el servidor puede hacer peticiones. Rechaza todo lo que no esté en la lista. Nunca uses una blocklist (denylist): las variantes de bypass son casi infinitas (0x7f000001, 127.1, registros DNS propios, IPv6 ::1, etc.).

# Pseudocódigo Python — allowlist estricta
ALLOWED_HOSTS = {"api.provider.com", "webhooks.service.io"}
ALLOWED_PORTS = {80, 443}

def fetch_url(url):
    parsed = urllib.parse.urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        raise ValueError("Host no permitido")
    if parsed.port not in ALLOWED_PORTS:
        raise ValueError("Puerto no permitido")
    # Resolver la IP y verificar que NO es privada
    ip = socket.gethostbyname(parsed.hostname)
    if ipaddress.ip_address(ip).is_private:
        raise ValueError("Destino privado bloqueado")
    return requests.get(url, allow_redirects=False, timeout=5)

2. Bloquear redirecciones

Configura el cliente HTTP para NO seguir redirecciones automáticamente (allow_redirects=False en Python requests, CURLOPT_FOLLOWLOCATION=false en PHP/cURL). Si la lógica de negocio requiere seguirlas, re-valida cada URL de destino contra la allowlist.

3. Deshabilitar esquemas peligrosos

Acepta únicamente https:// y en casos justificados http://. Rechaza explícitamente file://, gopher://, dict://, ftp://, sftp:// y cualquier otro esquema no esperado. Muchas librerías HTTP los soportan por defecto.

4. Segmentación de red

El principio de mínimo privilegio aplicado a la red: el servidor de aplicación no debe tener acceso directo a servicios de administración internos. Separa la red donde corre la aplicación web de la red donde residen bases de datos, paneles de control y servicios de infraestructura mediante VLANs y reglas de firewall que apliquen un «deny all» por defecto.

5. Forzar IMDSv2 y deshabilitar IMDSv1 en AWS

Aunque IMDSv2 es el modo por defecto en instancias EC2 nuevas desde marzo de 2024, IMDSv1 sigue existiendo y debe deshabilitarse explícitamente en las instancias antiguas. La OWASP SSRF Prevention Cheat Sheet trata IMDSv2 como un control de defensa en profundidad que mitiga parte de los casos de SSRF en AWS. Comprueba el estado de tus instancias y, mejor aún, impón IMDSv2 a nivel de cuenta para que cualquier instancia configurada con IMDSv1 falle al lanzarse.

Cómo prevenirlo — Resumen para desarrolladores

Vulnerabilidad Medida principal Medidas complementarias
CSRF Token anti-CSRF sincronizado en todo formulario de cambio de estado SameSite=Strict en cookies de sesión; verificación de cabecera Origin
SSRF Allowlist estricta de hosts y puertos permitidos No seguir redirecciones; rechazar esquemas peligrosos; segmentación de red; IMDSv2

Integra estas comprobaciones en el proceso de revisión de código y en las pruebas automatizadas (DAST en el pipeline CI/CD). Herramientas como OWASP ZAP pueden detectar CSRF y ciertos SSRF de forma automática.

Ejercicio propuesto

Ejercicio A — CSRF en DVWA

  1. Levanta DVWA (la del Módulo 1, accesible en http://localhost:4280) y autentícate.
  2. Configura la seguridad en nivel Low. Ve a la sección CSRF.
  3. Observa el formulario de cambio de contraseña con Burp Suite: ¿hay token CSRF?
  4. Crea una página HTML en tu máquina local que auto-envíe el formulario POST al cambiar la contraseña por pwned123.
  5. Abre la página en el mismo navegador donde tienes la sesión activa de DVWA. Verifica que la contraseña ha cambiado.
  6. Sube la seguridad a Medium: ¿qué defensa aparece? ¿Puedes bypassearla? ¿Y en nivel High?

Ejercicio B — SSRF en PortSwigger Web Security Academy

  1. Accede a portswigger.net/web-security/ssrf con cuenta gratuita.
  2. Completa el lab «Basic SSRF against the local server»: intercepta la petición de stock con Burp, modifica el parámetro para apuntar a http://localhost/admin y elimina un usuario.
  3. Completa el lab «Basic SSRF against another back-end system»: enumera la red interna 192.168.0.X:8080 con Burp Intruder para encontrar el panel de administración.
  4. (Avanzado) Completa «Blind SSRF with out-of-band detection» usando Burp Collaborator para confirmar el SSRF sin respuesta visible.

Estos laboratorios son gratuitos y no requieren instalación. Si te interesa profundizar en hacking web con certificación, consulta nuestra guía de cursos y certificaciones de ciberseguridad, donde encontrarás opciones como el eJPT (entrada) y el BSCP de PortSwigger.

Errores comunes

En CSRF

  • Confiar en SameSite como única defensa: tiene bypasses documentados. Úsalo siempre junto con tokens.
  • Tokens predecibles: generar el token con timestamp o Math.random() en lugar de un CSPRNG es insuficiente.
  • Token en URL: incluir el token CSRF como parámetro GET lo expone en logs del servidor, caché y cabecera Referer.
  • No invalidar el token al cerrar sesión: si el token persiste, un atacante con acceso a un token antiguo puede reutilizarlo.
  • Proteger solo el login: CSRF afecta a cualquier acción autenticada que cambie estado, no solo al inicio de sesión.

En SSRF

  • Usar blocklist en lugar de allowlist: los bypasses son casi infinitos (IP en octal, decimal, hexadecimal, IPv6, registros DNS propios que resuelven a 127.0.0.1).
  • No verificar la IP resuelta: validar el hostname sin resolver la IP real permite ataques DNS rebinding: el DNS devuelve una IP pública durante la validación y una IP interna al realizar la petición.
  • Seguir redirecciones sin re-validar: la librería HTTP sigue la redirección de trusted.com hacia 192.168.1.1 y la allowlist del hostname inicial ya no aplica.
  • Ignorar esquemas no HTTP: file:///etc/passwd, gopher:// y dict:// pueden explotar SSRF en librerías que los soporten.
  • Mantener IMDSv1 activo en AWS: cualquier SSRF en una instancia EC2 con IMDSv1 expone credenciales IAM. Con IMDSv2 ya como modo por defecto en instancias nuevas (desde marzo de 2024), seguir con IMDSv1 en instancias antiguas es un error de configuración crítico y frecuente en auditorías y bug bounty.

Preguntas frecuentes

¿CSRF funciona en aplicaciones que usan JSON y tokens Bearer?

En la mayoría de los casos, no. Las aplicaciones SPA (Single Page Application) que usan tokens JWT en la cabecera Authorization no son vulnerables a CSRF clásico, porque el navegador no incluye automáticamente esa cabecera en peticiones cross-site. Sin embargo, si la misma aplicación usa también cookies de sesión para alguna funcionalidad, esa parte sí puede ser vulnerable. La clave está en qué mecanismo de autenticación usa cada endpoint.

¿SSRF solo afecta a aplicaciones con campos de URL visibles?

No. La superficie de ataque de SSRF incluye cualquier funcionalidad donde el servidor realice peticiones HTTP hacia recursos externos o internos: importadores de archivos por URL, webhooks, conectores de APIs, previsualizaciones de enlaces, validadores de feeds RSS/XML, librerías de procesamiento de imágenes (ImageMagick, Pillow con SVG), y más. La entrada del atacante no tiene por qué ser una URL explícita; puede estar embebida en un SVG, un documento XML o un archivo de configuración.

¿Cómo se reporta CSRF o SSRF en un programa de bug bounty?

Incluye en tu reporte: descripción técnica del endpoint vulnerable, PoC funcional (para CSRF, la página HTML; para SSRF, la petición manipulada con la respuesta), impacto concreto (qué datos o acciones quedan expuestos), y los pasos exactos para reproducirlo. Programas como HackerOne y Bugcrowd valoran especialmente el SSRF con acceso a metadatos cloud (suele clasificarse como Critical) y el CSRF sobre funciones críticas (cambio de email, contraseña, datos de pago). Para iniciarte en bug bounty, consulta nuestra guía completa de hacking web.

¿Qué diferencia hay entre CSRF y Clickjacking?

Ambos abusan de la sesión del usuario, pero de forma diferente. CSRF fuerza al navegador a enviar peticiones HTTP directamente desde código malicioso (sin que el usuario vea nada). Clickjacking embebe la aplicación legítima en un <iframe> invisible y superpone una interfaz falsa para que el usuario haga clic en elementos de la aplicación real sin saberlo. Las defensas también difieren: la cabecera X-Frame-Options: DENY o la directiva frame-ancestors 'none' de CSP previenen clickjacking, pero no CSRF.

Recursos oficiales

Recordatorio legal y ético (cierre): las técnicas descritas en este módulo son herramientas de conocimiento defensivo. Reproducirlas fuera de entornos de laboratorio autorizados — incluyendo sistemas de terceros en internet — constituye un delito en España según el artículo 197 bis del Código Penal, con penas de prisión de hasta dos años que se agravan si afectan a datos sensibles o sistemas críticos. Antes de cualquier auditoría, obtén autorización escrita del propietario del sistema. Si eres estudiante, mantén toda tu práctica en DVWA, OWASP Juice Shop, PortSwigger Web Security Academy y entornos de laboratorio propios. El objetivo de este curso es que seas capaz de encontrar y corregir estas vulnerabilidades, no de explotarlas sin permiso. Si quieres canalizar estos conocimientos de forma profesional y remunerada, explora los programas de bug bounty responsable.