O Reflected File Download (RFD) é uma vulnerabilidade que permite que um invasor crie um URL ou uma página de phishing que, quando visitada, inicia o download de um arquivo com conteúdo arbitrário que parece ter se originado de um domínio confiável. Como o usuário confia em um determinado domínio, é provável que ele abra o arquivo baixado, resultando possivelmente na execução de código mal-intencionado.

Para que um invasor execute um ataque RFD bem-sucedido, os seguintes requisitos devem ser atendidos:
- O aplicativo de destino reflete a entrada do usuário sem validação ou codificação adequada. Isso é usado para injetar uma carga útil.
- O aplicativo de destino permite URLs permissivos. O invasor pode, portanto, controlar o nome e a extensão do arquivo baixado.
- O aplicativo de destino tem um cabeçalho Content-Disposition configurado incorretamente, o que permite que o invasor controle os cabeçalhos Content-Type e/ou Content-Disposition na resposta HTTP ou o aplicativo de destino inclui um Content-Type que não é renderizado por padrão no navegador.

Por exemplo, se o aplicativo usa um Spring Web MVC ContentNegotiationManager para produzir dinamicamente diferentes formatos de resposta, ele atende às condições necessárias para tornar possível um ataque RFD.

O ContentNegotiationManager está configurado para decidir o formato de resposta com base na extensão do caminho do pedido e para usar o Java Activation Framework (JAF) para encontrar um Content-Type que melhor corresponda ao formato solicitado pelo cliente. Ele também permite que o cliente especifique o tipo de conteúdo de resposta por meio do tipo de mídia que é enviado no cabeçalho Accept da solicitação.

Exemplo 1: No exemplo a seguir, o aplicativo é configurado para permitir a estratégia de extensão do caminho e o Java Activation Framework para determinar o tipo de conteúdo da resposta:

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

Exemplo 2: No exemplo a seguir, o aplicativo é configurado para permitir o cabeçalho Accept da solicitação para determinar o tipo de conteúdo da resposta:

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

Observe que os padrões de configuração ContentNegotiationManagerFactoryBean no Spring 4.2.1 são:

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

A configuração mostrada no Example 1 permite que um invasor formule uma URL mal-intencionada, como:

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

de maneira que ContentNegotiationManager usará o Java Activation Framework (se activation.jar for encontrado no classpath) para tentar resolver o tipo de mídia para a extensão de arquivo fornecida e definir o cabeçalho ContentType da solicitação de forma adequada. Neste exemplo, a extensão do arquivo é "bat", resultando em um cabeçalho Content-Type de application/x-msdownload (embora o Content-Type exato possa variar, dependendo do sistema operacional do servidor e da configuração JAF). Como resultado, assim que a vítima visitar esse URL mal-intencionado, sua máquina iniciará automaticamente o download de um arquivo ".bat" contendo conteúdo controlado pelo invasor. Se este arquivo for executado, a máquina das vítimas executará quaisquer comandos especificados pela carga útil do invasor.

Uma Falsificação de Solicitação no Lado do Servidor ocorre quando um invasor pode influenciar uma conexão de rede estabelecida pelo servidor de aplicativos. A conexão de rede se originará do IP interno do servidor de aplicativos, e um invasor pode usar essa conexão para ignorar os controles de rede e verificar ou atacar recursos internos que não seriam expostos.

Exemplo: No exemplo a seguir, um invasor pode controlar a URL à qual o servidor está se conectando.

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

A capacidade do invasor de sequestrar a conexão de rede depende da parte específica do URI que pode ser controlada e das bibliotecas usadas para estabelecer a conexão. Por exemplo, controlar o esquema de URI permite que o invasor use protocolos diferentes de http ou https, como:

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

Um invasor pode aproveitar essa conexão de rede sequestrada para executar os seguintes ataques:

- Varredura de portas de recursos de intranet.
- Desvio de firewalls.
- Ataque a problemas vulneráveis em execução no servidor de aplicativos ou na Intranet.
- Ataque a aplicativos Web internos/externos usando ataques de Injeção ou CSRF.
- Acesso a arquivos locais usando o esquema file://.
- Em sistemas Windows, o esquema file:// e caminhos UNC podem permitir que um invasor varra e acesse compartilhamentos internos.
- Realização de um ataque de envenenamento de cache DNS.

A Linux Standard Base Specification 2.0.1 para libc impõe restrições nos argumentos para algumas funções internas [1]. Se essas restrições não forem atendidas, o comportamento das funções não será definido.


O valor 1 sempre deve ser transmitido ao primeiro parâmetro (o número de versão) da seguinte função do sistema de arquivos:

	__xmknod

O valor 2 sempre deve ser transmitido ao terceiro parâmetro (o argumento de grupo) das seguintes funções de cadeia de caracteres largos:

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

O valor 3 sempre deve ser transmitido como o primeiro parâmetro (o número de versão) das seguintes funções do sistema de arquivos:

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

Dependendo do compilador C específico em uso, o endereço de um objeto FILE do sistema pode ser significativo para o uso do objeto FILE como um fluxo. Usar uma cópia do objeto FILE sem o endereço associado pode levar a um comportamento indefinido, resultando em um possível vazamento de informações do sistema, uma falha do sistema ou na capacidade de um agente mal-intencionado ler ou editar arquivos a seu critério.

Exemplo 1: O código a seguir mostra um objeto FILE do sistema que é desreferenciado e copiado por valor.

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

Como sysfile é desreferenciado na atribuição de insecureFile, o uso de insecureFile pode resultar em uma ampla variedade de problemas.

A realização de operações de arquivo em um objeto FILE do sistema após seu fluxo associado ser fechado resulta em comportamento indefinido. Dependendo do compilador C específico em uso, a operação do arquivo pode causar uma falha no sistema ou até mesmo resultar na modificação ou leitura do mesmo arquivo ou de um arquivo diferente.

Exemplo 1: O código a seguir mostra uma tentativa de ler um objeto FILE do sistema após o fluxo correspondente ser fechado.

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

Como a função getc() é executada após o fluxo de arquivo para sysfile ser fechado, getc() resulta em comportamento indefinido e pode causar uma falha no sistema ou possível modificação ou leitura do mesmo arquivo ou de um arquivo diferente.

Excluir um ponteiro gerenciado fará com que o programa trave ou execute ações impróprias quando, mais tarde, o código de gerenciamento de ponteiro supor que o ponteiro ainda é válido. O exemplo a seguir ilustra o erro.

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

A única exceção a essa regra é quando uma classe de ponteiro gerenciado oferece suporte a uma operação de "separação", permitindo que o programador assuma o controle de gerenciamento da memória para o ponteiro especificado. Se o programa desconectar o ponteiro da classe de gerenciamento antes de chamar delete, essa classe não saberá mais usar o ponteiro.