Reflected file download Scenario

Question

I'm making a Java-based web application that is intentionally vulnerable to Reflected File Download (RDF). White paper is here I read the requirements of reflected file download vulnerability as being:

• User has control over the file name (filename in content-disposition header is missing).
• app uses values found in URL (or other places controlled by user) to create content of file. In other words, some user input is being "reflected" to the response content.
• response is being downloaded (instead of rendered in browser) and a file is 'created on the fly' i.e. programatically.

I have a servlet named FileDownload and I don't specifying the filename in the content-disposition header:

   response.setHeader("Content-Disposition","attachment");

In an ordinary request (http://localhost:8080/FileDownload), I get a file named FileDownload as expected (though, it has a .sql extension for reasons I do not understand)

The pdf says,

Adding a "/" to the end of the path portion followed by a desired filename and extension is supported cross browser.

but I did not immediately get this behavior, instead it could not find that resource. So, I changed my web.xml from

<url-pattern>/FileDownload</url-pattern>

to

<url-pattern>/FileDownload/*</url-pattern>

and that enabled the behavior described above in the URL: http://localhost:8080/FileDownload/Setup.bat. So, the url-pattern has to be extra permissive for this to work?

The paper also asserts that all "This type of file could harm your computer..." warnings are "dismissed" if one of the following strings appear in the filename: Install, Setup, Update, Uninst. I did not see this behavior. Has this been changed since the article was released?

The point of RFD is abusing the trust of certain sites and if I can make arbitrary files look like they are coming from a trusted site, I get to bypass certain warnings. (Is it my browser that already trusts certain sites or is it the user or both?)

I was surprised to see that semi-colon patterns such as

http://localhost:8080/FileDownload;/Install.bat

http://localhost:8080/FileDownload;/Install.bat;Install.bat 

work as described in the paper. However, if I can achieve the same result with http://localhost:8080/FileDownload/Install.bat, then under what scenario would I need to do the semi-colon hack?

To make any of this work, I also had to set my browser to automatically download files without asking me where to save them.

Answer 1

The point of RFD is abusing the trust of certain sites and if I can make arbitrary files look like they are coming from a trusted site, I get to bypass certain warnings. (Is it my browser that already trusts certain sites or is it the user or both?)

I think it is only meant as in the user will look at the downloaded file and think "Oh, it did come from www.google.com, so it should be safe", and then execute it. But I could be wrong.

However, if I can achieve the same result with http://localhost:8080/FileDownload/Install.bat, then under what scenario would I need to do the semi-colon hack?

Did you use IE / Firefox? The paper states in section 2.2.2 that the "hack" is only needed for Chrome / Opera. (But then again, you seem to have solved it without using a single ";", which was not described in the paper. The paper does however state "Of course, that application specific URL parsing could lead to other characters acceptable as separators in the path portion of the URL.").