Qué es SSRF: el servidor como mensajero

Imagine que usted le pide a un mensajero de confianza que vaya a buscar un paquete a una dirección que usted escribe en un papel. El mensajero tiene un gafete que le abre todas las puertas del edificio de la empresa. Si nadie revisa qué dirección escribió usted, podría mandarlo a la bóveda del sótano en lugar de a la tienda de la esquina. Eso, en esencia, es la falsificación de solicitudes del lado del servidor, conocida por sus siglas en inglés SSRF (Server-Side Request Forgery).

Qué es, en una frase

Una SSRF es una falla en la que un atacante logra que el servidor haga solicitudes a destinos que él elige, incluidos destinos internos que el atacante no podría alcanzar por su cuenta.

Para entenderla necesita una idea previa: en la web, el cliente (su navegador) pide cosas y el servidor (la aplicación) responde. Pero el servidor también puede actuar como cliente de otros servicios: muestra la vista previa de un enlace pegado en un chat, importa una foto desde una URL o avisa a un webhook. En todos esos casos, el usuario aporta una URL y el servidor la visita. El problema aparece cuando la aplicación no limita a dónde puede ir esa solicitud. El servidor vive dentro de la red, detrás del firewall, y alcanza cosas que un visitante de internet nunca vería: paneles internos, bases de datos con interfaz HTTP o el servicio de metadatos de la nube.

Navegador del atacante --> Aplicación pública --> Servicio interno
      (internet)            (zona expuesta)        (red privada)

El atacante no rompe el firewall: convence a un servidor que ya está dentro de que haga la solicitud por él. Por eso la solicitud está falsificada: parece legítima porque sale de un equipo de confianza.

InternetRed interna

◀▶Paso 1 de 4

1. 1)El firewall lo detiene. Desde internet, el atacante no alcanza los servicios internos: el firewall solo deja pasar el tráfico hacia la aplicación pública.
2. 2)Le pasa una URL a la app. Usa una función legítima, como la vista previa de un enlace o importar una imagen, pero escribe una URL que apunta a un destino interno.
3. 3)La app la visita desde dentro. El servidor, que vive en la red privada, hace la solicitud: panel de administración, base de datos o metadatos de la nube.
4. 4)La respuesta vuelve al atacante. Si la aplicación muestra el resultado, el atacante lee lo que nunca habría podido pedir directamente.

Por qué ocurre

La causa raíz casi siempre es la misma: confiar en una URL que controla el usuario sin validar su destino real. Detrás suele haber una función pensada solo para el caso feliz, una validación que revisa el texto de la URL y no la IP a la que se conecta, una librería que sigue redirecciones sola y una red interna que confía en todo lo que viene de dentro.

Breve historia

En 2021 no entró por ser la falla más frecuente en los datos, sino porque la comunidad la señaló en la encuesta como un riesgo creciente por el auge de la nube y los microservicios. Que en 2025 se agrupe con el control de acceso no la hace menos grave: en el fondo, es una forma de saltarse los límites de acceso de la red.

La debilidad principal se cataloga como CWE-918: Server-Side Request Forgery.

Por qué importa en su trabajo

• Desarrolladores: cada función que recibe una URL es un sumidero potencial.
• Revisores autorizados: la SSRF suele estar entre los hallazgos más graves de una auditoría web en la nube.
• Analistas de SOC: un intento deja huellas en la aplicación, el proxy y la nube; hay que cruzarlas.
• Ingenieros de nube: IMDSv2, la segmentación y el mínimo privilegio son la última barrera.

Sin ese dominio, lo típico es una "corrección" que bloquea el texto 127.0.0.1 y deja la puerta abierta.

Dónde aparece

Conceptos clave

Cómo leer las fichas del curso

En una sintaxis, los corchetes indican partes opcionales, las MAYÚSCULAS son valores que usted reemplaza y ... indica que se puede repetir. Para pedir ayuda, use comando --help o man comando en la terminal y help(funcion) en Python.