3

We have a requirement to allow users to upload an XML document into our system. We don't process it, we just allow them to download it again.

Given various browser XSS vulnerabilities such as this: http://webstersprodigy.net/2012/02/04/serving-back-xml-for-xss/ (various flavours affecting IE, Chrome and FF)

What is our best approach for safely allowing users to download the document again? Things we've considered so far:

  • Wrap the document in a ZIP file for download
  • Use a plain/text content type (we've got all the disable content-sniffing headers enabled but haven't yet tested what IE 8 will do in this scenario)
  • Something else entirely?
  • if the same user who uploads the xml is the one to download it, what is the risk? a user will not XSS himself – aviv Jan 21 '15 at 9:22
  • The documents are visible to other users (within the same tenant) – James Crowley Jan 21 '15 at 9:38
1

There are some ways to do this.

  1. Check if XML contains any malicious code.
  2. Double encode the XML. (https://www.owasp.org/index.php/Double_Encoding)

You could also encrypt the XML when uploading, and decrypt when downloading.

.Htaccess should also be edited to force the user to download instead of viewing in the browser(http://www.michaelbarton.name/2010/01/14/how-to-force-a-download-with-a-save-as-prompt-using-a-htaccess-file-andor-apache/)

  • Encrypting the XML when downloading wouldn't solve the issue - because the malicious file would still execute in our users browser? – James Crowley Jan 21 '15 at 10:20
  • My bad, forgot to mention .Htaccess modification. – GaringoXXS Jan 21 '15 at 10:25
  • Just to note we already had the equivalent of the .htaccess modification in place, but that doesn't solve the issue because the user can still choose to open the file (it just won't happen automatically), and certain browsers will still open this as if it was on the domain (rather than running it as a local file) – James Crowley Feb 11 '15 at 18:00
1

When a user clicks to view an XML file, simply set the content-disposition header to force a download to the local machine rather than a displaying in the browser.

Content-Disposition: attachment; filename=foo.xml;

Of course the user then needs to be careful what they do with the saved XML, but clicking to download now won't automatically trigger an XSS attack.

  • We already have this set, but if the user clicks 'Open' you are still vulnerable to the XSS because IE opens it on the domain. – James Crowley Jan 22 '15 at 23:10
  • @JamesCrowley: Even in combination with setting content-type to text/plain? – SilverlightFox Jan 23 '15 at 10:10
  • It seems so - at least when tested in IE 8, by that point I suspect it's just using the file extension. – James Crowley Jan 23 '15 at 15:08
0

It seems that zipping is a valid option. I dont know how all browsers will behave with plaintext content type, my guess is that that is OK as well but who knows, maybe some old version might recognize that you are downloading XML and try to override the content type...

If you want to be really nice to your user's you can scan the uploaded files for malicious content and remove the sus. There are cloud services who offer this service such as Virus Total

  • Thanks, Virus Total looks interesting - though unfortunately doesn't pick our malicious test files as malicious because I presume they're going after known virus signatures? Looks like we'll go the ZIP route for now – James Crowley Jan 21 '15 at 10:23
0

You could something like this:

  • On Upload you would rename the file to .txt and when downloading force with extension .xml.
  • You could use the option you mention of the zip file, but then you need to think in something to preview the file. (if you need this option)

To the preview part its important that you implement some XSS Filter Evasion. This should be enough to protect you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.