Drupal Solutions to Mime Type Detection XSS

This article presents an overview of two methods to solve a cross site scripting problem that affects older versions of Safari and Internet Explorer versions 8 and below (to varying degrees). If you are unfamiliar with XSS or how bad it is, please first read Introduction to Cross Site Scripting (XSS) and Drupal.

How to exploit Internet Explorer Mime Type Detection XSS

What is the IE Mime Type Detection Cross Site scripting Issue? The "mime type" is a way that computers know what to do with a document. The mime type is often associated with a file extension (e.g. filename.txt is usually a file with a mime type of text/plain). That isn't always the case, of course. You can, for example, take an HTML document and change the extension to .txt and it still contains HTML, but which tool should your computer use to open that file? This is where mime-type detection comes into play. Internet Explorer tries to figure out the file type, even if it has a specific extension. If you allow the upload of "txt" files to your site then a malicious user can put HTML into those files and any visitor to your site using an Internet Explorer browser to download that txt file will actually get HTML, in all it's glory. This video shows a quick demonstration of the problem.

There are two main ways to exploit this vulnerability:

• use the HTML-in-txt to host Javascript code as an XSS attack vector
• create an HTML page that looks just like the login page but sends the form POST to a malicious user's site and "phish" an admin user of the site

How can you solve these problems?

Using Webserver configuration to serve text as an attachment

If the files are downloaded instead of being read in the browser then there is no opportunity for XSS and the Phishing attack would just be confusing. Read Force Files to Download Instead of Showing Up in the Browser from the Drupal handbook.

This behavior can have an undesirable UX downside, so consider whether or not this is appropriate for your environment.

1. Using a CDN to move files directory to a new domain

The CDN - Content Delivery Network module allows you to serve your site's files from a different URL. It's main purpose is to add performance: using separate cookie-free domains, especially from CDN providers who have geographically dispersed servers, to deliver common files like your CSS and Javascript can accelerate page render performance. In this case it has a separate benefit: if the malicious .txt file comes from a separate domain then the browser Same Origin Policy will limit the XSS to running on the separate domain where there is no Drupal installation.

So there's no need to actually purchase and work with an external CDN service (especially since it could be expensive to host all your files there). Instead:

• Create two domains that point to the same server(s)
• One is your main Drupal server (e.g. example.com), one is your site just for files (e.g. files-example.com) - it's important you use a separate domain and not just a subdomain
• Configure the files-example.com webroot to contain a symlink to the regular files directory of examples.com
• Enable the CDN module with the "Origin Pull" mode - in this case your method of "pulling" files is just the symlink
• In the Apache configuration for example.com, deny access to the files directory (e.g. sites/example.com/files)

This idea works in theory, but not practice: there is an issue in the CDN module queue to get it to actually work.

A workaround in the short-term until that issue is fixed would be to do web server level 301 redirect from your sites/example.com/files/ directory to files-example.com/sites/example.com/files/).

2. Don't allow txt uploads

This is of course an easy solution: disable text file uploads. That said, other file types have their own problems. Most "Office Productivity" file formats like Microsoft Office and LibreOffice allow some form of programming like VBA in Microsoft office which can be a vector for attacks. PDF readers on client machines are often out of date and can have their own vulnerabilities. In a site where the admins are all running controlled corporate computers with up-to-date software and virus-scanners it may be more acceptable to simply disallow text file uploads.

3. Analyze uploads and reject inappropriate ones

There is an issue for Core to Mitigate the security risks that come from IE and other browsers trying to sniff the mime type . The idea is to do something like the ClamAV module: analyzing files as they are uploaded to see if their mime type matches their extension and rejecting files that don't match. The issue even links to an existing PHP library which can be used to perform mime-type detection in a fashion identical to Internet Explorer. A sandbox project by Erik Webb hopes to achieve a similar goal and has an issue to support IEcontentAnalyzer.