The web application took a user inputted description for a dataset that was used in several places. It was passed through several layers of validation for output to the screen and to a CSV file for download. However, it was also used as the filename for the CSV download and was not subject to enough validation. The filename was written to the HTTP headers as an attachment, e.g.:
Content-Disposition: attachment; filename="output.csv"However, if we want to add a redirect header to the response from the server then we have to manipulate the filename/description. If we add a CRLF (carriage return line feed – i.e. a new line) then we can add a new header, such as:
Refresh: 0; url=http://www.google.com/#q="password.csv"This will redirect the user's browser to the URL after 0 seconds, i.e. give them no chance to abort it. We need to send the CRLF ASCII character codes to the server to force it to put a new line in. This can be achieved by adding %0d%0a (CRLF) into the description. In this case the .csv" was added to the end automatically, which could be ignored by the malicious website or used as in this example above. So the full description becomes:
output.csv" %0d%0aRefresh: 0; url=http://www.google.com/#q="passwordThe output of this in the HTTP Header is:
Content-Disposition: attachment; filename="output.csv"In this case, though, I came up with a problem. If I used the above injection I got the following error:
Refresh: 0; url=http://www.google.com/#q="password.csv"
Error 500: Invalid LF not followed by whitespaceIt turns out that the character set is not properly dealt with by the web server. You cannot just add a space after the codes either as this will appear as a space at the beginning of the header line that we are injecting, which is interpreted by the browser as a continuation of the previous header line. The solution came from https://www.aspectsecurity.com/blog/to-redacted-thanks-for-everything-utf-8/ where overly long data is inserted knowing that it will be truncated to the correct codes. The following codes will be truncated to the CRLF:
%c4%8aNow the working attack payload becomes:
output.csv" %cc%8aRefresh: 0; url=http://www.google.com/#q="passwordThe simplest way to fix this is to use a hardcoded output filename, e.g. output.csv. The user can change this when they download it if they want. Otherwise, more sophisticated validation is required to look for certain character codes and sequences.