Fix code SpringBoot SSRF - Exploiting URL Parser

Este tipo de vulnerabilidades se da cuando un atacante tiene la habilidad de hacer que el servidor objetivo inicie una nueva conexión contra otro equipo, independientemente de si al equipo remoto al que se conecta se encuentra dentro o fuera de su red interna.

En la mayoría de los casos en donde un ataque de “SSRF” adquiere un mayor nivel de criticidad es en los entornos en los que a través de ésta técnica es posible conectarse a equipos en la red local y que de otro modo sería imposible acceder a ellos desde una red externa.

Este ataque no solo aplica a conexiones HTTP, sino que puede ser combinado con otro tipo de ataques como “XML External Entities”, o incluso extrapolado a otro tipo de protocolos como conexiones de SQL Server en las que mediante la modificación de la cadena de conexión es posible acceder a servidores SQL localizados en la red local. En 2010 ya se habló por primera vez de este último ataque (“CSPP – Connection String Parameter Pollution“) junto con la combinación con un “SSRF”.

En cuanto a la detección de este tipo de vulnerabilidades, no resulta trivial debido a que podemos encontrar este error en diversos entornos y/o protocolos, e incluso algunos de ellos no muestran una alteración en la respuesta a la solicitud, por lo que la única forma de “cazarlos” es en base a un sistema que detecte la conexión saliente.

Ejemplo:

                    

• Urls parser por lenguaje de programación:

private static void getEmployees(String uri)
{
     
    RestTemplate restTemplate = new RestTemplate();
    String result = restTemplate.getForObject(cleanUrl(url), String.class);
    
    System.out.println(result);
}

    /**
   * cleanUrl 
   * @param url
   * @return
   * @throws EncodingException
   */
  public static String cleanUrl(String url) throws EncodingException {
    return ESAPI.encoder().decodeFromURL(ESAPI.encoder().encodeForURL(url));

  }
}

más info: [CB17] A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!