Risks of serving untrusted content under HTTP Content-Type: text/plain?

Question

Am I gonna run into XSS attacks by doing this, or will a file download be prompted?

Are there security problems that would rise in a modern browser?

Answer 1

Am I gonna run into XSS attacks by doing this

Yes.

The text/plain->text/html content-type-sniffing issue mentioned by curiousguy is the most likely attack, but there are also many more cases where browsers and plugins do content-sniffing; often these are immune to X-Content-Type-Options and Content-Disposition:.

For example the jar: URL scheme under old Firefoxen, Java applets and Flash crossdomain policy injection (loadPolicyFile).

The only sure-fire way to serve arbitrary untrusted content without being at risk of XSS is to serve it from a different domain* that doesn't share an origin with your main site.

*: variants: full different second-level domain with different IP address is tightest. There are issues with applets being able to make network connections to the same IP address even if the domain is different under Java. Using a subdomain may be OK subject to limitations - if it's files.example.com the main site in that case would have to be on www.example.com and not example.com, to avoid that the subdomain can read cookies from the parent. It can still write cookies, which in some cases can cause problems. Using a direct IP address for the untrusted content is another reasonable alternative if you don't want to buy a separate domain.

Answer 2

Some very badly broken browsers (notably old IE versions) try to "snif" the "true" content-type and will act as if the content-type was text/html.

Perhaps you can try to blacklist said browsers, either according to user-agent or by providing HTML as text and checking if the browser runs JavaScript in text/plain.

If you want the browser to save the file instead of display it, try Content-Disposition (f.ex. Content-Disposition: Attachment; filename=example.txt).

IE8 Security

You can also use the X-Content-Type-Options: nosniff IE-specific HTTP header in order to prevent MIME-sniffing of text/plain HTTP resources.

Sites hosting untrusted content can use the nosniff directive to ensure that text/plain files are not sniffed to anything else.