While testing an application, I found that an authenticated user has the ability to upload a file for a claim. The upload button is designed to allow for the upload of .docx files.
After a user uploads a file, it can be downloaded. A comparison between the uploaded .docx file and the downloaded.docx file showed that they were different, which would imply that some processing is done on the file before being hosted for download.
While the file being uploaded must be a valid .docx, it is possible to modify the file extension. I changed the file extension to .html.
When the file with a .html extension is retrieved from the server, the Content-Type header is set to text/html. This causes the browser to attempt to render the file as HTML.
I then attempted to smuggle and XSS payload within a valid .docx file. Because the file type is compressed, I needed to identify an area within the file body that would not be modified during compression or by post-processing from the application. It was found that certain file paths within the file structure were not modified during the upload process. I modified the filename of Settings.xml within a .docx file to pad it with characters.
The server accepted the upload of the modified .docx file. The file extension was modified to .html during the HTTP POST.
When requesting the file, it was served as an HTML file with the XSS payload intact.
To obfuscate this attack, an attacker could include the URI of the upload within a small or invisible iframe to keep the victim from noticing the payload being executed. For this example, a visible payload is displayed.