View Issue Details

IDProjectCategoryView StatusLast Update
0003876Composrcorepublic2019-11-14 21:21
ReporterhexifeAssigned ToChris Graham 
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0003876: XSS vulnerability via mime sniffing on .dat files
DescriptionHTML(XHTML) file can be uploaded in "Home→ Content Management→ Downloads→ Add download" feature.
(It needs to modify extension to upload-able extension, and edit extension and content-type in the HTTP Request via web debugger (e.g. fiddler, burp). Maybe there is client-side filter in the feature.)

If the file upload is succeed, the path of uploaded file (~.dat) is exposed in its HTTP Response.
(I attached the example image.)

In Apache2 environment (I tested in ubuntu environment) with default setting, when the user access the uploaded file via URL(~.dat file), Web Server couldn't find the content-type of uploaded file and Web server do not set the content-type. It makes the web browsers trying to found file's MIME-Type using their content-sniffing algorithm. If the contents of the file is HTML, Browser determines it as HTML and render it.

As the result, JavaScript in the uploaded file could be executed in the client browser. (Stored XSS)
TagsType: Security
Attach Tags
Time estimation (hours)
Sponsorship open



2019-09-16 15:16


composr.png (56,223 bytes)
composr.png (56,223 bytes)
composr_2.png (14,153 bytes)
composr_2.png (14,153 bytes)

Chris Graham

2019-09-16 16:59

administrator   ~0006085

Thanks for your report, and posting it as private.

It looks like this is a legitimate bug. I was not aware browsers still did content sniffing.

We'll respond in more detail soon.

Chris Graham

2019-09-18 02:13

administrator   ~0006087

Possible fixes to be considered, early stage:
1) Change .dat extension to .bin, which Apache will give an application/octet-stream mime type rather than NO mime type -- add mime handling of .bin handling for IIS via bundled web.config (
2) Add "X-Content-Type-Options: nosniff" header in bundled .htaccess and web.config
3) Stop using .dat file extension, use original file extension (something to consider in general, but it would require the web server to have mime types set up for every whitelisted file extension - so not plausible to fix this security issue on its own)
4) Make sure direct HTTP access is disabled from any directory with .dat files in

We may do some combination of these things for defense in depth.

Chris Graham

2019-09-23 02:06

administrator   ~0006096

This issue is fixed in


a) Changes .dat to .bin, which is confirmed to have an application/octet-stream mime type in IIS and Apache. Most browser sniffing won't allow JS to run if an explicit non-JS mime type is being specified, so this alone should fix the issue for any newly uploaded files.
b) Adds "X-Content-Type-Options: nosniff" to the default root .htaccess files and default web.config file. This actually doesn't help to solve the original issue as reported, because (i) Firefox will not consider this header for URLs with no mime type defined [Chromium is okay] (ii) Users would have to manually make the change to the files they have already configured. However, it is good to have this header for possible cases of browsers doing more aggressive mime sniffing.
c) Adds "X-Content-Type-Options: nosniff" and CSP JS-blocking HTTP headers into many directories, basically any that doesn't already completely block web access and doesn't have web pages served from (Composr already sets "X-Content-Type-Options: nosniff" in all its own PHP web requests). This fixes the problems with 'b' because these are not user-edited files, and the CSP will block all JS even if the mime type of old .dat files was sniffed.
d) Generally reviewed all .htaccess files to make sure they are optimal, and added extra testing to ensure consistency here

Direct URL access to uploads/downloads remains, as internally the download system is written under the assumption that every download is associated with a URL. While internally it is passing through dload.php, not every system will necessarily be aware of it.

A second minor vulnerability was found during testing - Composr's internally-generated SVG files for stats graphs had publicly accessible and guessable URLs, leading to leaking of stats data. This has also been fixed, by blocking direct URL access to these files.

Additionally some extra testing is added for v11 to compare Composr-defined mime types against IIS and Apache, to ensure consistency
This isn't directly related to this vulnerability, but I thought better auditing of our use of mime types will be important.

This issue is not yet public, as work continues on it, and we need to work out exactly how to advise users of the issue. Likely users will be given an option to solve it via a single .htaccess change to add a .dat mime type and add the "X-Content-Type-Options: nosniff" header (which should work for the vast majority of users), rather than applying the full upgrade.

Issue History

Date Modified Username Field Change
2019-09-16 15:16 hexife New Issue
2019-09-16 15:16 hexife Tag Attached: Type: Security
2019-09-16 15:16 hexife File Added: composr.png
2019-09-16 15:16 hexife File Added: composr_2.png
2019-09-16 16:59 Chris Graham Note Added: 0006085
2019-09-18 02:13 Chris Graham Note Added: 0006087
2019-09-23 02:06 Chris Graham Note Added: 0006096
2019-09-25 02:01 Chris Graham Severity trivial => Security-hole
2019-09-25 02:01 Chris Graham Summary HTML(XHTML) file could be uploaded in download feature of admin page and rendered under specific server environments. => XSS vulnerability via mime sniffing on .dat files
2019-09-25 02:01 Chris Graham Description Updated View Revisions
2019-09-26 02:31 Chris Graham Category downloads => core
2019-09-26 02:43 Chris Graham View Status private => public
2019-11-14 21:21 Chris Graham Assigned To => Chris Graham
2019-11-14 21:21 Chris Graham Status non-assigned => resolved
2019-11-14 21:21 Chris Graham Resolution open => fixed