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?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
Am I gonna run into XSS attacks by doing this
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
For example the
jar: URL scheme under old Firefoxen, Java applets and Flash crossdomain policy injection (
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.
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
If you want the browser to save the file instead of display it, try
Content-Disposition: Attachment; filename=example.txt).
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.