Thanks for your report. I don't think that it has security implications.

"any user, which can upload .txt files to the some web-server can make large .txt file, and successfully inject arbitrary content there."

With a web-server under control, you can serve any kind of data for any URL.

As for "Content-Type:text/plain" being ignored, I believe that's intended behavior as per https://cs.chromium.org/chromium/src/content/common/loader_util.cc?rcl=7fb06bca6072d21575fb3e7f495aa50f0ecc17bf&l=37


It shouldn't happen if the server sets "X-Content-Type-Options: nosniff" header, but it doesn't:


$ curl -i https://xpoc.pro/security.txt | more
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Nov 2017 19:00:40 GMT
Content-Type: text/plain
Content-Length: 1929852571
Last-Modified: Mon, 20 Nov 2017 17:13:40 GMT
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: antibot-hostia=true; path=/; domain=xpoc.pro; expires=Tue, 21-Nov-2017 19:00:40 GMT
ETag: "5a130d44-7307369b"
Accept-Ranges: bytes

Eߣ�B��
B��
B��B�B��matroskaB��B��S�g

The point was in next:
Let's assume, that server allows text user content to be uploaded, but no media. In this case this restriction can be bypassed using large .txt files with video content (or other media content)

The X-Content-Type-Options is actually set for all files, but because this file is very big (around 2 GB) - this header will be returned only after complete file loading (and Chrome read it in chunks). That's why you are not seeing it i think.

Look for example to the https://xpoc.pro/security2.txt - little file. It returns X-Content-Type-Options, because it is small, and was loaded fast.

You should be abble to reproduce this issue by downloading the https://xpoc.pro/security.txt and deploing it on your own host, with setting X-Content-Type-Options header

Using Chrome Browser, the file will respond with 200 and further multiple 206 Partial Content codes because of Transfer-Encoding: chunked header in the 1st response, with no X-Content-Type-Options header, even if it strictly set in the web server's config.

Sorry, it appeared to be nginx bug, when the server was unable to set X-Content-Type-Options header for the large files.
The MIME sniffing didn't work with different server version (which set X-Content-Type-Options correctly)
My apologizes for taking your time.