3

I have a web application where user can upload and view files. The user has a link next to the file (s)he has uploaded. Clicking on the link will open the file in the browser (if possible) or show the download dialog (of the browser). Meaning that, if the user upload an html/pdf/txt file it will be rendered in the browser but if it is a word document, it will be downloaded. The file url is like https://mydoma.in/ran-dom-guid.

It is identified that rendering the HTML file in the browser could be a vulnerability - Cross Site Scripting. That is, since the file is executed under my domain, it is possible to attack if it contains a malicious script.

What is the right solution to this problem? The two options I am currently looking at are:

  1. to put Content-Disposition header in the response to make HTML files downloaded instead viewed in the browser.
  2. to find some html scrubbing/sanitizing library to remove any javascript from the file before I serve it.

Looking at the gmail, they do the second approach (of scrubbing) with having a separate domain for the file download - may be to minimize/distract the attack surface. However in this approach the receiver gets a different file than what was sent. Which is not 'right' in my opinion; may be I am biased. In my case, the first one is easy to fix. But I wonder if that is enough, or is there any thing that I overlook!

What are your thoughts on these approaches? Or do you have any other suggestions?

Improve this question
3
  • The use case is not sufficiently clear for me: 1. Can the user only see/download files they've uploaded themselves? 2. Viewing a HTML file and downloading it have a different purpose. Presenting these as both as possible solutions is strange for me. What is the behavior actually expected by the user?
    – Steffen Ullrich
    Jan 8, 2021 at 15:26
  • Here are the answers: 1. User can see the files they have uploaded only; but one can fake the user with a malicious html file. 2. The primary purpose is to store documents that user gets from different sources and access them later. When accessing, the goal is to show the file with in the browser itself if possible (for better user experience) which is not possible always hence there is download as a fallback.
    – Mahesh V S
    Jan 8, 2021 at 15:34
  • Would it be sufficient if any kind of script in the HTML is disabled when viewing inline? If yes sandboxed iframe should do it, i.e. simply <iframe sandbox src=....>. It is supported in all modern browsers.
    – Steffen Ullrich
    Jan 8, 2021 at 15:47

1 Answer 1

Reset to default
1

Security-wise, the first solution is better. Forcing a download via content-disposition is simple and clean.

HTML parsing and sanitizing on the other hand is a complex task with lots of room for error, possibly allowing an attacker to still perform XSS attacks. Additionally, you'd also need to worry about other attacks related to the SOP (eg CSRF if your CSRF defense is a referer check, Clickjacking, etc).

Usability-wise, it seems that you would prefer the second approach though (the user can view the file directly instead of having to download it). Going with a well-established library is a good idea in that case.

Alternative approaches might be isolated subdomains (probably one per user) serving the files, or sandboxed iframes displaying the content (configured as restricted as possible for your use-case, and taking other SOP issues under consideration).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .