4

I'm creating a small web script that mostly redirects the browser but has some error conditions when input parameters cannot be validated.

I'd like to display error messages like parameter XXX had invalid value YYY but that would open the script to XSS attacks if the parameter value is not properly escaped before output. Is it safe enough just to set the Content-Type of the response to text/plain or are XSS attacks still possible?

chiborg
  • 643
  • 1
  • 6
  • 12
  • 1
    http://stackoverflow.com/questions/30897884/is-it-safe-to-rely-on-content-type-text-plain-to-mitigate-malicious-javascript – bayo Aug 19 '15 at 11:50

1 Answers1

10

You must not rely on browsers respecting the content-type header for security. A quick look at CVE-2010-1420 should give you an idea. Content-sniffing mechanism implemented in browsers can be manipulated by attackers to trigger XSS attacks (Secure Content Sniffing For Web Browsers: A Survey).

Survey of content sniffing behaviors

enter image description here

According to this survey, as you may see, Safari browser could cause a problem even this is not an issue in other browsers (I can add you Bug 637981 to this list).

Go further:

You can protect further your application by allowing your web server to force the browser into disabling MIME Sniffing for the served file:

  X-Content-Type-Options: nosniff

Since the attacks you are trying to defend against could be done via the files that you may allow today or tomorrow your visitors to upload, you can force the browser to present the user with a file save dialog. When the noopen header is set, the user can not open the file directly because he will be forced to save the file locally first, which prevents the file from being rendered in the current browser context. You can achieve that by:

Content-Disposition: attachment; filename=untrustedfile.html

Additionally, in this last case (I mean if you allow users to upload files), you can add an other security layer to your web application (Risky sniffing):

  • Use a whitelist to ensure that only a limited amount of file extensions are allowed
  • Store uploaded files outside the web root and use a secure download script that loads these files from disk and presents their contents to the user;
  • Use non-predictable filenames and change the file extension.
  • I like your answer, although you start by saying "you must not" and proceed to explain the nosniff option. I think a better TL;DR would be "you can with care" – paj28 Aug 19 '15 at 12:59
  • @paj28 I understand what you mean, but I proposed him the **Go further** section in case, for a reason or an other, the OP does not have time/skills or will to handle that properly in other ways. I mean, my answer responds to, and stays in, the OP's question context. Regards –  Aug 19 '15 at 13:12