SSRF y Componentes Vulnerables
Server-Side Request Forgery (SSRF)
El SSRF (Server-Side Request Forgery, CWE-918) es una vulnerabilidad que ganó tanta relevancia que el OWASP Top 10 le dedica su propia categoría (A10:2021). Ocurre cuando una aplicación obtiene un recurso remoto a partir de una URL proporcionada por el usuario sin validarla. El atacante consigue que el servidor realice peticiones en su nombre, usando la posición privilegiada del servidor dentro de la red.
Lo que hace al SSRF tan peligroso es que el servidor suele tener acceso a recursos internos que el atacante no puede alcanzar directamente: servicios en la red interna, bases de datos, paneles de administración o, en entornos de nube, los endpoints de metadatos que exponen credenciales temporales de la instancia. Un SSRF puede así convertirse en la puerta de entrada a la red interna o en el robo de credenciales de nube, escalando de un parámetro aparentemente inofensivo a un compromiso serio de la infraestructura.
Cómo Prevenir el SSRF
La defensa más robusta contra el SSRF es no confiar nunca en URLs proporcionadas por el usuario para realizar peticiones del lado del servidor. Cuando la funcionalidad lo requiera, valida la URL con una lista de permitidos estricta: solo dominios y rutas explícitamente autorizados, en lugar de intentar bloquear los peligrosos con una lista de denegados, que siempre se puede eludir.
Como capas adicionales, resuelve y valida la dirección IP de destino para bloquear rangos internos y de loopback, deshabilita las redirecciones automáticas o valídalas también, y restringe los protocolos permitidos a http y https. A nivel de red, aplica segmentación y reglas de firewall de salida para que, aunque el SSRF ocurra, el servidor no pueda alcanzar servicios internos sensibles. En la nube, usa la versión más reciente y endurecida del servicio de metadatos. La combinación de validación de entrada y segmentación de red es la defensa en profundidad adecuada.
Deserialización Insegura
La deserialización insegura (CWE-502) ocurre cuando una aplicación reconstruye objetos a partir de datos serializados que provienen de una fuente no confiable. La serialización convierte objetos en un formato transmisible; la deserialización los reconstruye. Si un atacante puede manipular los datos serializados, en algunos lenguajes y bibliotecas puede manipular qué objetos se crean y qué métodos se invocan durante el proceso de reconstrucción.
El impacto puede llegar hasta la ejecución remota de código en el servidor, uno de los peores escenarios posibles. La prevención principal es evitar deserializar datos no confiables siempre que sea posible. Cuando necesites intercambiar datos, prefiere formatos puramente de datos como JSON con esquemas estrictos, en lugar de la serialización nativa de objetos del lenguaje. Si debes deserializar objetos, firma criptográficamente los datos para verificar su integridad, restringe los tipos que se pueden deserializar y ejecuta el proceso con los mínimos privilegios posibles.
Componentes y Dependencias Vulnerables
Las aplicaciones modernas se construyen sobre cientos de bibliotecas de terceros. El OWASP Top 10 dedica la categoría A06:2021 — Vulnerable and Outdated Components a este riesgo, y es enorme precisamente por su escala: una sola dependencia vulnerable, posiblemente una que ni siquiera sabías que tenías (una dependencia transitiva), puede comprometer toda la aplicación. Incidentes históricos como las vulnerabilidades en frameworks y librerías ampliamente usadas afectaron a miles de organizaciones simultáneamente.
El problema se agrava porque las dependencias quedan desactualizadas silenciosamente. Una librería que era segura cuando la añadiste puede tener una vulnerabilidad descubierta meses después. Sin un proceso para detectar y actualizar estos componentes, acumulas deuda de seguridad invisible. Aquí entran también las vulnerabilidades de tipo cliente, donde scripts de terceros cargados en tu página pueden ser comprometidos.
Seguridad de la Cadena de Suministro
La seguridad de la cadena de suministro (supply chain) consiste en gestionar el riesgo que introducen todos los componentes externos de los que depende tu software. El primer paso es la visibilidad: mantén un inventario actualizado de todas tus dependencias, idealmente generando un SBOM (Software Bill of Materials) que liste cada componente y su versión.
Sobre esa base, integra el análisis de composición de software (SCA) en tu pipeline de desarrollo: herramientas que comparan tus dependencias contra bases de datos de vulnerabilidades conocidas (CVE) y te alertan cuando aparece una nueva. Automatiza las actualizaciones de seguridad, fija versiones para evitar cambios inesperados y verifica la integridad de los paquetes que descargas. Reduce tu superficie eliminando dependencias que no usas. Combina esto con las herramientas que hemos mencionado a lo largo del curso, Burp Suite, OWASP ZAP y los escáneres SAST/DAST, para una postura completa. Tu aplicación es tan segura como su componente más débil, incluso si ese componente lo escribió otra persona.