El SSRF (Server-Side Request Forgery) abusa de una función que hace que el servidor realice peticiones a una URL controlada por el usuario. Si la URL no se valida, el atacante apunta a recursos internos que desde Internet no son accesibles.
Por qué es peligroso el SSRF
- Alcanzar servicios de la red interna (paneles, bases de datos, otros microservicios).
- Leer el servicio de metadatos de la nube (la dirección interna
169.254.169.254en AWS/GCP/Azure), que puede exponer credenciales temporales del servidor. - Escanear puertos internos usando al servidor como puente.
POST /importar → url=http://169.254.169.254/latest/meta-data/
El servidor obedece y devuelve datos internos que no deberían salir.
Defensa del SSRF: validar la URL contra una lista blanca de destinos permitidos, bloquear rangos internos y de metadatos, resolver y verificar la IP final, y deshabilitar redirecciones no controladas.
Deserialización insegura
Serializar es convertir un objeto en una cadena para guardarlo o enviarlo; deserializar es reconstruirlo. La deserialización insegura ocurre cuando la app reconstruye datos no confiables del usuario. Un objeto manipulado puede ejecutar código al reconstruirse (RCE).
Defensas:
- No deserializar datos que vengan del usuario; si hace falta, usar formatos de solo-datos como JSON con un esquema estricto.
- Firmar o cifrar los objetos que sí deban viajar (integridad).
- Mantener librerías actualizadas (muchos exploits son cadenas de gadgets conocidas).
Ambas fallas comparten una raíz: confiar en datos que vienen de afuera. La próxima ataca el sistema de archivos del servidor: subida de archivos y LFI/RFI, el próximo tema.