La descarga de archivos reflejados (RFD) es una vulnerabilidad que permite a un atacante crear una dirección URL o página de suplantación de identidad (phishing) que, cuando se visita, inicia la descarga de un archivo con contenido arbitrario que parece haberse originado en un dominio de confianza. Debido a que el usuario tiene confianza en el dominio dado, es probable que abra el archivo descargado, lo que podría resultar en la ejecución de código malintencionado.

Para que un atacante ejecute con éxito un ataque RFD, se deben cumplir los siguientes requisitos:
- La aplicación de destino refleja la entrada del usuario sin la validación o codificación adecuadas. Esto se usa para inyectar una carga útil.
- La aplicación de destino permite direcciones URL permisivas. Por lo tanto, el atacante puede controlar el nombre y la extensión del archivo descargado.
- La aplicación de destino tiene un encabezado Content-Disposition mal configurado que permite al atacante controlar los encabezados Content-Type o Content-Disposition en la respuesta HTTP, o la aplicación de destino incluye un encabezado Content-Type que no se representa de forma predeterminada en el explorador.

Por ejemplo, si la aplicación usa una instancia de ContentNegotiationManager de Spring Web MVC para producir dinámicamente diferentes formatos de respuesta, cumple las condiciones necesarias para hacer posible un ataque RFD.

La instancia de ContentNegotiationManager está configurada para decidir el formato de respuesta en función de la extensión de la ruta de acceso de la solicitud y para utilizar Java Activation Framework (JAF) para encontrar un encabezado Content-Type que se adapte mejor al formato solicitado por el cliente. También permite al cliente especificar el tipo de contenido de la respuesta mediante el tipo de medio que se envía en el encabezado Accept de la solicitud.

Ejemplo 1: En el siguiente ejemplo, la aplicación está configurada para permitir que la estrategia de extensión de ruta de acceso y Java Activation Framework determinen el tipo de contenido de la respuesta:

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="favorPathExtension" value="true" />
  <property name="useJaf" value="true" />
</bean>

Ejemplo 2: En el siguiente ejemplo, la aplicación está configurada para permitir que el encabezado Accept de la solicitud determine el tipo de contenido de la respuesta:

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="ignoreAcceptHeader" value="false" />
</bean>

Tenga en cuenta que los valores predeterminados de la propiedad ContentNegotiationManagerFactoryBean en Spring 4.2.1 son:

- useJaf: true
- favorPathExtension: true
- ignoreAcceptHeader: false

La configuración que se muestra en el Example 1 permite a un atacante crear una URL malintencionada, como:

http://server/some/resource/endpoint/foo.bat?input=payload

de forma que la instancia de ContentNegotiationManager utilizará Java Activation Framework (si el archivo activation.jar se encuentra en el objeto classpath) para intentar resolver el tipo de medio para la extensión de archivo dada y establecer el encabezado ContentType de la respuesta en consecuencia. En este ejemplo, la extensión de archivo es "bat", lo que da como resultado un encabezado Content-Type de application/x-msdownload (aunque el valor exacto de Content-Type puede variar según el sistema operativo del servidor y la configuración de JAF). Como consecuencia, una vez que la víctima visita esta dirección URL malintencionada, su máquina iniciará automáticamente la descarga de un archivo ".bat" que con contenido controlado por el atacante. Si luego se ejecuta este archivo, la máquina de la víctima ejecutará cualquier comando especificado por la carga útil del atacante.

Se produce una falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.

String url = request.getParameter("url");
CloseableHttpClient httpclient = HttpClients.createDefault();
HttpGet httpGet = new HttpGet(url);
CloseableHttpResponse response1 = httpclient.execute(httpGet);

La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

Linux Standard Base Specification 2.0.1 para libc establece restricciones en los argumentos de algunas funciones internas [1]. Si no se cumplen las restricciones, no se define el comportamiento de las funciones.


El valor 1 debe transferirse al primer parámetro (el número de versión) de la siguiente función del sistema de archivos:

	__xmknod

El valor 2 debe transferirse al tercer parámetro (el argumento de grupo) de las siguientes funciones de cadenas de caracteres amplias:

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

El valor 3 debe transferirse como primer parámetro (el número de versión) de las siguientes funciones del sistema de archivos:

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

En función del compilador de C específico que se utilice, la dirección de un objeto ARCHIVO del sistema puede ser importante para el uso del objeto ARCHIVO como una secuencia. El uso de una copia del objeto ARCHIVO sin la dirección asociada puede generar un comportamiento indefinido que resulte en una posible fuga de información del sistema, un fallo del sistema o la capacidad de un actor malintencionado de leer o editar archivos a su discreción.

Ejemplo 1: El siguiente código muestra un objeto ARCHIVO del sistema al que se le desreferencia y se copia por valor.

FILE *sysfile = fopen(test.file, "w+");
FILE insecureFile = *sysfile;

Como sysfile se desreferencia en la asignación de insecureFile, el uso deinsecureFile puede resultar en una amplia variedad de problemas.

Realizar operaciones de archivos en un objeto ARCHIVO del sistema después de cerrar su secuencia asociada da como resultado un comportamiento indefinido. En función del compilador de C específico que se utilice, la operación del archivo puede provocar un fallo del sistema o incluso provocar la modificación o lectura del mismo archivo o de uno diferente.

Ejemplo 1: El siguiente código muestra un intento de leer un objeto ARCHIVO del sistema después de cerrar la secuencia correspondiente.

FILE *sysfile = fopen(test.file, "r+");
res = fclose(sysfile);
if(res == 0){
    printf("%c", getc(sysfile));    
}

Como la función getc() se ejecuta después de que la secuencia del archivo para sysfile esté cerrada, getc() da como resultado un comportamiento indefinido y puede provocar un fallo del sistema o una posible modificación o lectura del mismo archivo o de uno diferente.

La eliminación de un puntero administrado provocará que el programa se bloquee o se comporte incorrectamente cuando, más adelante, el código de administración del puntero asuma que el puntero sigue siendo válido. El ejemplo siguiente ilustra el error.

  std::auto_ptr<foo> p(new foo);
  foo* rawFoo = p.get();
  delete rawFoo;

La única excepción a esta regla aparece cuando una clase de puntero administrado es compatible con una operación "desasociar" lo que permite al programador tomar el control de la administración de la memoria para un puntero determinado. Si el programa desasocia el puntero de la clase de administración antes de llamar delete, la clase de administración sabrá que no puede seguir utilizando el puntero.