Reflected File Download

The application allows an attacker to craft a URL that forces a download of arbitrary content that appears to have originated from a trusted domain.

Reflected File Download (RFD) is a vulnerability that allows an attacker to craft a phishing URL or page that, when visited, initiates a download of a file containing arbitrary content appearing to have originated from a trusted domain. Because the user has trust in the given domain, he or she is likely to open the downloaded file, potentially resulting in malicious code execution.

In order for an attacker to run a successful RFD attack, the following requirements need to be met:
- The target application reflects user input without proper validation or encoding. This is used to inject a payload.
- The target application allows permissive URLs. The attacker may therefore control the downloaded file's name and extension.
- The target application has a misconfigured Content-Disposition header, allows the attacker to control the Content-Type and/or Content-Disposition headers in the HTTP response, or the target application includes a Content-Type that is not rendered by default in the browser.

For example, if the application uses a Spring Web MVC ContentNegotiationManager to dynamically produce different response formats, it meets the conditions necessary to make an RFD attack possible.

The ContentNegotiationManager is configured to decide the response format based on the request path extension and to use Java Activation Framework (JAF) to find a Content-Type that better matches the client's requested format. It also allows the client to specify the response content type through the media type that is sent in the request's Accept header.

Example 1: In the following example, the application is configured to allow path extension strategy and Java Activation Framework to determine the response's content type:

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

Example 2: In the following example, the application is configured to allow the request's Accept header to determine the response's content type:

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

Note that the ContentNegotiationManagerFactoryBean property defaults in Spring 4.2.1 are:

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

The configuration shown in Example 1 allows an attacker to craft a malicious URL such as:

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

such that the ContentNegotiationManager will use Java Activation Framework (if activation.jar is found in the classpath) to try to resolve the media type for the given file extension and set the response's ContentType header accordingly. In this example, the file extension is "bat", resulting in a Content-Type header of application/x-msdownload (although the exact Content-Type may vary depending on the server OS and JAF configuration). As a result, once the victim visits this malicious URL, his or her machine will automatically initiate the download of a ".bat" file containing attacker-controlled content. If this file is then executed, the victims machine will run any commands specified by the attacker's payload.