# SSRF Server Side Request Forgery (SSRF) ocurre cuando un atacante fuerza a una aplicación a hacer peticiones HTTP en su nombre. La mayoría de los atacantes aprovecha esta vulnerabilidad para publicar o leer datos finales sensibles como el servicio de metadatos de AWS y Gcloud, el serviio FTP, el servicio LDAP y los archivos locales. Cuando se buscan vulnerabilidades SSRF, se suele buscar peticiones que tengan una URL con valor de parámetro. Si la respuesta se refleja de vuelta al atacante, podría tener una posible vulnerabilidad SSRF. ## Ejemplo El siguiente paso es encontrar un endpoint vulnerable en el host local del sistema o en un endpoint de la red local. ![](https://i.imgur.com/5wa6Xnz.png) en la petición anterior se ha cambiado el valor de "stockApi" a un directorio de administración en la IP local del sistema. la petición será realizada por la aplicación, por lo que realizará una resquest contra sí misma. este endpoint tiene una aplicación de administración alojada en el host local, normalmente sería imposible acceder a ella desde internet, pero gracias a SSRF podemos hacerlo. ![](https://i.imgur.com/id8OYK5.png) Si renderizamos la respuesta html, podemos ver que somos capaces de acceder a una aplicación interna internón a alojada en el sistema de destino.Si renderizamos la respuesta html, podemos ver que somos capaces de acceder a la aplicación de administarinterna alojada en el sistema de destino. La parte más difícil de la SSRF es demostrar el impacto de la vulnerabilidad.Encontrar una aplicación que seria dificil vulnerar sin usar SSRF. si no podemos encontrar un endpoint que nos lleve al host local, se ienvia peticiones a servidores de la red interna del objetivos . Si te encuentras en una aplicación alojada en Google Cloud o en otros proveedores de la nube, puedes intentar leer la información de la aplicación alojada en alojada en Google Cloud o en otros proveedores de la nube, puedes intentar leer los servicio de metadatos para recuperar las claves y credenciales de la API. ## Recomendaciones Para desabilitar esta vulnerabilidad debemos tener en cuenta los siguientes métodos: - Deshabilitar redirecciones - Usar whitelist para los dominios aceptados - Usar expresiones regulares para establecer un patrón aceptable - Restringir los protocolos habilitados - El puerto de solicitud de restricción solo puede ser un puerto web, solo permitiendo el acceso a las solicitudes HTTP y HTTPS - las solicutudes externas no pueden acceder a la IP de Intranet