To see the exploit in action run the application using the default Maven profile. For example, from the command line you can execute one of the following commands:

The application will now be running on port 8080.

You can now request the URL from IE:

http://localhost:8080/%22%7C%7Ccalc%7C%7C.bat

This will result in the output of:

and will open the calculator application on windows.

To see the patched in action run the application using the patched Maven profile. For example, from the command line you can execute one of the following commands:

The application will now be running on port 8080.

You can now request the URL from IE:

http://localhost:8080/%22%7C%7Ccalc%7C%7C.bat

This will result in the output of:

Since the Content-Disposition header is added along with a filename of f.txt the calculator application will not work.

Practically speaking, we have found always adding the Content-Disposition header is quite disruptive. This is because developers (and DevOps) often make these API requests in the browser when they are developing/troubleshooting.

If a download is forced it adds quite a bit of extra work (i.e. the file must be opened, viewed, and then deleted). It is also quite surprising that typing https://example.com/configuration.yml into the browser results in downloading a file named f.txt. Forcing the download with a constant filename can also add a potential additional step of renaming the files if multiple files need to be viewed at once (i.e. in order to remember which file is which).

You can find some of the feedback we have received in the Spring JIRA

To alleviate this, Spring does not add the Content-Disposition header if a malicious file extension is not found as a path parameter or a file extension. For example, requesting the following URL

http://localhost:8080/%22%7C%7Ccalc%7C%7C

will result in the output of:

Since there is no executable file extension in the URL, the file is not considered executable and the calculator application will not work.

1. AbstractMessageConverterMethodProcessor will find all extensions in the last path segment of the requested URL. This includes path variables and the suffix of the last path segment.

2. If any of the extensions found in step 1 are not in our whitelist, then the Content-Disposition header is added. Our updated whitelist is planned to include:

"txt", "text", "yml", "properties", "csv", "json", "xml", "atom", "rss", "png", "jpe", "jpeg", "jpg", "gif", "wbmp", "bmp"

We have also observed that there were lots of file extensions mapped to image/*, audio/*, video/*, and +xml that are likely to cause similar pain points. Rather than explicitly listing all of these extensions he thought it might be easier to leverage the mime types that they map to. For example, Spring would first find all file extensions in the URL (i.e. step 1). Spring would then compare each file extension against a whitelist of their respected media types. For example, if the path contained .svf, that maps to a mime type of image/vnd.svf Since the mime type is image we would allow it.

One other mime type that we considered adding was text/*. The reason is that we wanted to allow all types of text to be rendered too (i.e. .html). A concern here is that if a company mapped a .bat, .pl, etc file to text/plain that this would mean the RFD attack would then be allowed.