User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36/7vdq8CtK-01

Steps to reproduce:

1. Open the PHP File locally (using the Local storage protocol)
2. You can see the image is rendered

Actual results:

PHP file was rendered and Image was shown, most probably due to the MIME-Sniffing where the firefox saw the first few bytes of the document and rendered it

Expected results:

If it is looking at the first few bytes and rendering it as a PHP file, it should also respect the CSP

Observation:
When we try the HTML file in Chrome and Firefox, both have the same behavior:
Chrome:
Refused to load plugin data from 'http://www.w3school.com.cn/i/eg_tulip.jpg' because it violates the following Content Security Policy directive: "object-src 'none'".
Firefox: Content Security Policy: The page’s settings blocked the loading of a resource at http://www.w3school.com.cn/i/eg_tulip.jpg (“object-src”).

The thing is when we try the PHP file, it should be shown as content-type: text/plain but it had different behavior and that didn't respect the CSP policy of blocking the image which we were loading in the <object> tag.

Expected result:
It should be in content-type:plain-text form. If it isn't in the plain text form as Chrome or Chromium-based browsers, it should respect CSP and should have blocked

Actual result:

1. It doesn't show the file as content-type:text/plain
2. It didn't block the image from loading.

In the Video PoC, we can see that it turned the CSP into a comment, and no idea why the PHP file was opened and wasn't shown as plain text.

Observations:
When we try the HTML

The file:/// protocol is really just reading the bytes from disk as you, the user supplies them.
If you are reading them from disk, naturally, nobody is executing the PHP code and therefore the header can't be set.
In fact, file:// does not know a concept of headers.
Ultimately, we can't respect any headers that aren't effectively set. You'll notice that when you open the file in Firefox and click on "View Source" - the browser tried to interpret the PHP source code as HTML/JavaScript.

In fact, if that PHP file had a PHP-comment containing HTML/JavaScript, the browser would happily accept that as well.
That's not a security bug. The same would be true for a .xyz file.

It might be a bug that we are trying to sniff documents from file:// into HTML when the ending is ambiguous.
I'll take that.

The file:/// protocol is really just reading the bytes from disk as you, the user supplies them.
--> That's what, I wanted to convey that it is most probably looking at the first 100 bytes of data and it lead to content-sniffing

If you are reading them from disk, naturally, nobody is executing the PHP code and therefore the header can't be set.
--> Exactly and that's why it is turned in the comment <---! in the video poc. It was expected that it will be text/plain

That's not a security bug. The same would be true for a .xyz file.
--> I doubt that it won't be a security bug but yes, ready to accept it as a bug over vulnerability too if I can see that it isn't exploitable because there are many cases when it is exploitable which is seen as likely here. In the past, I'd similar content-sniffing of CSS in Yandex browser which was exploited at an edge case of UXSS, I will ask the team to provide the consent to make the case public and can share the exploitation stuff here. There are many content sniffing cases that are sometimes exploited for example:
https://bugs.chromium.org/p/chromium/issues/detail?id=1160665
This is clearly a good example of a content-sniffing case that should usually not be performed by modern browsers. It can be exploited on sites that e.g. allow uploading and viewing plain-text files. As the browser would then see that it contains HTML, and thus render it (including the embedded JavaScript code).
This isn't through HTML but of PHP which is local so, yes, its impact will decrease drastically but I won't be good to accept it as a bug and not a vulnerability. :)

Not only this much but in this case, it can be seen that the header wasn't set even though the developer sets the header which ended up loading the image. Are you sure that it won't have any kind of exploit scenario? Because in the example of CSP it actually stripped out the header and loaded the image and there can be similar cases which I am not aware of, at the moment.

(In reply to Frederik Braun [:freddy] from comment #3)

It might be a bug that we are trying to sniff documents from file:// into HTML when the ending is ambiguous.
I'll take that.

FWIW, I would expect that we try to map the filename to a mimetype, and that we use the OS's mapping of file extensions to mimetypes for this. Exactly how this pans out may differ depending on both the OS (Windows vs. macOS vs. Linux) and installed software (which will alter the registry on Windows and perhaps mimetype info on e.g. Linux)

If there's a possibility of exploiting this case then it will be of low priority like this Chromium Bug. But you can see in the Chromium Bug too, they have marked it as low priority and affects windows but in the case of Firefox it will be in all the operating systems except Android because it isn't working for me as expected, I am not able to open Local HTML if it will open then it is through content schema, my device is Xiaomi Redmi Note 5 Pro. Also, what Freddy sir said in his comment #3 is acceptable too due to one of the many reasons:

The file:/// protocol is really just reading the bytes from disk as you, the user supplies them.

The browser interprets PHP code. So, of course, the header doesn’t get set, when the file is loaded from the local file system. PHP is a server-side programming language. But wait does Firefox has a default MIME type mapping for .php? Btw, a good idea came to my mind but currently in hospital so, can't try it but here is the idea: The same would probably happen when we host the PHP file on a server that doesn’t have a PHP interpreter installed/activated. Can somebody try and share an observation? If not, I can update it here by next week.

Was that Firefox does not interpret PHP code, so it didn’t know that there should be a CSP.? If yes, it is like expecting Firefox to check a CSP in a plain text file, just because the term Content-Security-Policy is in there, yes? As there is nothing telling the browser about any CSP because that header turned into a comment, the image was loaded and not due to any vulnerability. So, I would also accept the below statement of freddy sir at some point:

That's not a security bug. The same would be true for a .xyz file.

I still haven't dug up much into this case but I will accept what he's saying more than counting this as a vulnerability. So, we should go as a bug and not a bug-security. It is at the discretion of the team if they think that this case is similar to local content sniffing through file:/// like Chromium Bug.

As this is a server-side language, one more thing which comes to our mind will be that the browser receives CSP from below two things:

1. The server's response headers
2. The corresponding meta tags in HTML code
   Please correct if it is wrong. :)

Another thing which Freddy sir hasn't said to us here might be from his statement:

Ultimately, we can't respect any headers that aren't effectively set. You'll notice that when you open the file in Firefox and click on "View Source" - the browser tried to interpret the PHP source code as HTML/JavaScript.

I was curious why that code turned into a comment but the hidden thing was in Freddy sir's comment line the browser tried to interpret the PHP source code as HTML/JavaScript and you know what the <? is no valid HTML entity and thus it didn't work, yes? But when we use meta tags, it is working as expected. :P Was the reason of entity due to which it turned into a comment?

GG. OP. :)

(In reply to Kirtikumar Anandrao Ramchandani from comment #7)

If you set needinfo, please be clear about what info you need / what question you need answered. At the moment, I can't tell. You appear to just be repeating what Freddy has already said.

in the case of Firefox it will be in all the operating systems except Android

Have you actually tested this? It's not clear on what OS you've tested except Android and Windows.

(In reply to :Gijs (he/him) from comment #8)

If you set needinfo, please be clear about what info you need / what question you need answered. At the moment, I can't tell. You appear to just be repeating what Freddy has already said.

Sorry as it was unclear about the questions. Jotting down all the questions here. The questions are:

1. Will this be a similar case like Chromium Bug? Or this won't be considered like that?
2. I requested team members to try this (comment #7):

Btw, a good idea came to my mind but currently in hospital so, can't try it but here is the idea: The same would probably happen when we host the PHP file on a server that doesn’t have a PHP interpreter installed/activated. Can somebody try and share an observation? If not, I can update it here by next week.

In the 2, my question is that if it is hosted on a server where the PHP interpreter isn't activated/installed, what is the outcome? Does it get an issue like the same as the file:/// URI? So, can somebody from the Mozilla Firefox team please try the above idea and additional information? Currently, I can't try but if this works then it can be an issue over Network protocol too and not just file:/// (Local Storage) URI. Thanks in advance.

Have you actually tested this? It's not clear on what OS you've tested except Android and Windows.

I have tested only on Android and Windows that's why I only replied for those two operating systems and didn't fluke for remaining.

(In reply to Kirtikumar Anandrao Ramchandani from comment #9)

1. Will this be a similar case like [Chromium Bug]? Or this won't be considered like that?

I don't know what you mean by "similar". I defer to Freddy about whether this should be considered a security bug, but it looks like he doesn't think so - if that's what you're asking.

If you're asking, is the root issue the same, I'm also not sure. I wouldn't be surprised if there was stupid info in the registry for PHP files. It wouldn't be the first time, cf. bug 1568003 which was partially a result of python files being listed as text/plain which they are clearly not...

2. I requested team members to try this (comment #7):

Btw, a good idea came to my mind but currently in hospital so, can't try it but here is the idea: The same would probably happen when we host the PHP file on a server that doesn’t have a PHP interpreter installed/activated. Can somebody try and share an observation? If not, I can update it here by next week.

I don't see how this is relevant or interesting. If the server without PHP is attacker-controlled, the whole thing is irrelevant, the attacker can just send whatever they like to the browser, they don't need a PHP-file-without-PHP-installed situation, it doesn't accomplish anything.

f the server is not attacker-controlled, why would it be serving attacker-controlled PHP, without a server compromise? If there's a server compromise, we're back at the first case (the attacker could just serve other content).

Either way it's not a browser issue. The browser doesn't understand or run or care about PHP. Broadly speaking, it only cares about HTML, and the headers it gets for HTML served over HTTP. For file documents there are no headers, so all we have to go on in is the filename and the file's contents.

Have you actually tested this? It's not clear on what OS you've tested except Android and Windows.

I have tested only on Android and Windows that's why I only replied for those two operating systems and didn't fluke for remaining.

You didn't, you said:

they have marked it as low priority and affects windows but in the case of Firefox it will be in all the operating systems except Android

which implies that the issue happens on other OSes besides Windows...