En una vulnerabilidad SSRF, el atacante no apunta directamente a la máquina que le interesa: usa el sitio como intermediario. El servidor web suele estar en una red desde la que puede llegar a servicios que nadie debería alcanzar desde Internet. Si una función del sitio descarga una URL facilitada por el usuario sin comprobar el destino, el atacante puede hacer que consulte esos servicios en su lugar. OWASP convirtió la SSRF en una categoría propia de su Top 10 de 2021 (A10), y MITRE la cataloga como CWE-918.
Cómo funciona un ataque SSRF
Las funciones afectadas son las que van a buscar una URL: importar una imagen desde una dirección, generar la vista previa de un enlace, llamar a un webhook, comprobar un feed. El atacante introduce en ellas una dirección interna en lugar de una pública:
- la dirección de metadatos de la nube
169.254.169.254, que usan AWS, Azure y Google Cloud, y que puede revelar credenciales y tokens de acceso; - el propio servidor (
localhost,127.0.0.1), por ejemplo un panel de administración o una base de datos que solo escucha en local; - la red privada (
10.0.0.0/8,192.168.0.0/16…), para trazar un mapa de las máquinas y los puertos abiertos; - otros protocolos distintos de HTTP, como
file://ogopher://, cuando la biblioteca utilizada los acepta.
La respuesta no siempre vuelve en claro: se habla de SSRF «ciega» cuando el atacante solo ve un mensaje de error o un tiempo de respuesta, lo que sin embargo basta para saber si un puerto está abierto.
Cómo protegerte
- Lista de permitidos: cuando los destinos son conocidos (una API concreta), acepta solo esos.
- Solo http y https, en puertos estándar.
- Rechazar las direcciones internas después de la resolución DNS, y comprobar también cada redirección: un nombre de dominio público puede apuntar a una dirección privada.
- En el alojamiento: segmentación de la red y, en AWS, paso a IMDSv2, que OWASP recomienda para limitar el robo de metadatos.
En WordPress: wp_safe_remote_get y los pingbacks
WordPress ofrece las herramientas adecuadas, siempre que se usen. wp_safe_remote_get() y sus variantes validan la URL y cada URL de redirección con wp_http_validate_url(): solo pasan http y https, se rechazan las credenciales dentro de la URL, se descartan las direcciones de bucle local y privadas, y un puerto explícito debe ser 80, 443 u 8080. En cambio, wp_remote_get() no hace esta validación por defecto: un plugin que la usa con una dirección facilitada por un visitante queda expuesto. El filtro http_request_host_is_external permite autorizar un host interno concreto; abrirlo a cualquiera anula la protección.
$respuesta = wp_safe_remote_get( esc_url_raw( $url_recibida ), array( 'timeout' => 5 ) );
if ( is_wp_error( $respuesta ) ) {
return; // URL rechazada o inalcanzable
}El propio núcleo sufrió este problema: antes de WordPress 3.5.1, el pingback de XML-RPC permitía enviar peticiones a servidores internos y escanear puertos (CVE-2013-0235). El pingback usa ahora wp_safe_remote_get(), pero sigue siendo una función que hace que tu servidor emita peticiones a petición de un tercero. Si no lo usas, el módulo de refuerzo de seguridad de WP Masquerade bloquea gratis los pingbacks y XML-RPC; nuestro artículo sobre XML-RPC te ayuda a comprobar que ningún servicio depende de ellos. Para lo demás, la SSRF se corrige en el código del plugin afectado, y un cortafuegos de aplicaciones web puede filtrar mientras tanto las direcciones internas más evidentes.