Reflected File Download

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.