SSRF
Los ataques de falsificaciĂłn de solicitudes del lado del servidor (SSRF) son otra forma de ciberdelito y están diseñados para apuntar especĂficamente a un servidor mediante el envĂo de solicitudes de back-end desde aplicaciones web vulnerables. Estos ataques pueden amenazar no solo a los servidores, sino tambiĂ©n a otra informaciĂłn confidencial conectada, como los servicios en la nube en AWS, Azure y OpenStack. Pueden ser especialmente difĂciles de combatir, ya que generalmente se usan para atacar sistemas internos protegidos por firewalls que son inaccesibles desde la red externa.
Riesgo del ataque
Robar datos sensibles como credenciales de usuarios o archivos de sistema.
Hacer peticiones a servicios internos para manejar el panel de administraciĂłn, escanear puertos y servicios dentro de la infraestructura interna y conectarse al servidor de correos para enviar correos sin autorizaciĂłn.
Escalar privilegios dentro del sistema y ejecutar cĂłdigo de forma remota dentro del servidor.
Mitigaciones
SegmentaciĂłn de la red para que el SSRF no afecte a toda la organizaciĂłn.
Deshabilitar redirecciones y sobre todo el uso de HTTP.
Usar whitelist para los dominios aceptados.
Usar expresiones regulares para establecer un patrĂłn aceptable.
Desinfectar y validar todos los datos de entrada proporcionados por el cliente.
Restringir los protocolos habilitados.
No envĂe respuestas sin procesar a los clientes.
CĂłdigo vulnerable
Esta funciĂłn para validar la url es insuficiente ya que no valida de forma segura la entrada del usuario, pudiendo poner este cualquier tipo de url.
Falta de validaciĂłn
function validUrl (url) {Â
return url
} |
SoluciĂłn
En este ejemplo podemos ver que la validación de la url es más segura ya que limitamos la entrada del usuario y lanzamos el comando "dnslookup" para conocer de qué forma resuelve el dominio.
Correcta validaciĂłn
function validUrl (url) {Â
Â
return url  Â
&& /^(http|https):\/\//.test(url)Â Â Â
&& !someIpChecker.isPrivate(url)Â Â Â
&& !someIpChecker.isPrivate(dnsLookup(url))
} |
RevisiĂłn continua
Es recomendable que no nos conformemos con una validaciĂłn al recibir los datos, sino que se sigan haciendo revisiones para evitar los cambios de direcciones DNS(o aceptar solo en los que confiemos) y redirecciones.
Referencias
https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/