files starting with `<img ` are incorrectly sniffed as HTML
Categories
(Core :: Networking, defect, P3)
Tracking
()
People
(Reporter: sachinnthakuri, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: reporter-external, Whiteboard: [necko-triaged])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Steps to reproduce:
When a file without extension or random extension is opened in Firefox, Firefox will automatically render it as an HTML. Thus allowing to run JS on so many contexts that opens up security risks for the users. This behaviour is shown only in Firefox and all other browsers such as Chrome and Safari handle it in a safe context.
To Reproduce:
- Simply open http://sop.cx/test or http://sop.cx/test.xxt and you will see a popup that shown JS being executed.
If you open the above links on other browsers you will see that they won't render it as an HTMl thus not allowing to execute JS.
Actual results:
When a file without extension or random extension is opened in Firefox, Firefox will automatically render it as an HTML. Thus allowing to execute JS.
Expected results:
The file should not be rendered as HTML as it is done with other browsers.
|
||
Comment 2•5 years ago
|
||
The neither of these files have a Content-Type: header; I think the MIME-sniffing spec would have us be well within our rights to content-sniff for html. (though it's odd Chrome and Safari don't, which I've confirmed on Mac).
http://sop.cx/test.txt (not mentioned in comment 0) is explicitly Content-Type: text/plain and we do the right thing there.
Anne: what's supposed to happen here?
|
|
||
Updated•5 years ago
|
|
|
||
Comment 3•5 years ago
|
||
(moved bounty request from bug 1718619 which seems like it was a double-submit)
|
Reporter | |
Comment 4•5 years ago
|
||
Hello,
Any updates on what is happening with this report?
|
||
Comment 5•5 years ago
|
||
These files start with <img and as per https://mimesniff.spec.whatwg.org/#identifying-a-resource-with-an-unknown-mime-type that cannot be sniffed as text/html. So this is a bug. (I don't think we have actively tried to maintain that code and match the specification.)
(Moving this to Networking for now. But DOM: Navigation is also somewhat suitable...)
|
|
||
Comment 6•5 years ago
|
||
Starting with <img is not really the point: an attacker could easily put a number of tags in front to make it work. When I do that we render it as HTML (this time with the blessing of the MIME sniffing spec) and Chrome continues to render the file as plain text.
Is the spec still valid? Can you find out from Chrome WHATWG contributors what their actual behavior is? Maybe they don't sniff HTML at all anymore? or only sniff specific extensions?
I'm not sure this needs to be a security bug. MIME sniffing is a well-known potential problem going back to IE days, and Firefox honors X-Content-Type-Options: nosniff which was created to address this problem. Still, sites may stop using that header if they find Chrome has gotten more strict, throwing spec-following browsers under the bus.
|
|
||
Comment 7•5 years ago
|
||
Can you share your test? If I create a file test.asis containing
HTTP/1.1 200 OKAY
<HTML><b>TEST</b>
and load it through web-platform-tests it renders as HTML in Chrome and Safari for me. Same if I replace HTML with br or head, but not if I replace it with td.
|
|
||
Comment 8•5 years ago
•
|
||
Ah, I was testing using file:// urls when I saw the behavior difference. When I use a web server and suppress the Content-Type: header then the Chrome and Firefox behavior match for the tags I tested from the MIME sniffing spec (e.g. <html>). In sum:
- there's a bug in our sniffing compared to the spec: we over-detect "HTML" (comment 5). Could be left-over historical behavior ("found any HTML tag near the beginning" or whatever we used). Given the content in this case it's not an unreasonable detection -- it is, in fact, intended as HTML content! But it does not match the spec or what Chrome and Safari do.
- By adding a single tag from the MIME sniffing spec this testcase will work just fine on other browsers (example:
<html><img src=x onerror=alert(8);>).
As a consequence of 2. this doesn't need to be a hidden security bug. The dangers of arbitrary user uploaded are well-known and the defenses that websites should take are the same regardless. Websites aren't going to parse the files and say "The MIME sniffing spec says this one isn't really HTML so I'll skip my defenses this time", they'll just apply the defenses regardless. potential defenses include:
- add the
X-Content-Type-Options: nosniffheader - make the file harmless by making sure it has the expected
Content-Type:, such astext/plain - make the file harmless by forcing a download (binary content type, or
Content-Disposition:header) - put user uploads on segregated origins, as done on this site for testcase attachments, or
*.github.io,*.googleusercontent.com, etc
|
||
Updated•5 years ago
|
|
||
Updated•2 years ago
|
|
||
Updated•1 year ago
|
Description
•