User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

After accesing my application, an iframe is rendered for the user. The iframe make a call in the browser location pointing to the address "autoskyplugin://SOMEPATH".

My application have the following CSP configuration for the frame-src: (frame-src 'self' autoskyplugin://*;)

Actual results:

After the 68.1.0 patch, my wildcard is not being respected, which means that the browser is blocking the iframe call.

After the render request is maded, the browser write an error in the console with following line:

Content Security Policy: As configurações da página bloquearam o carregamento de um recurso em autoskyplugin://SOMEPATH (“frame-src”).

Expected results:

The iframe should be rendered since my frame-src is using and wildcard after the "autoskyplugin://".

OBS: I've tested on another browsers (chrome) and the header wildcard is being respected, and the iframe is rendered without problems.

(In reply to hllrsr from comment #0)

After accesing my application, an iframe is rendered for the user. The iframe make a call in the browser location pointing to the address "autoskyplugin://SOMEPATH".

Just to be clear, you have a frame, and it redirects itself to an externally implemented protocol, and you expect this to call out to the external program because of the CSP including the external protocol. That is, autoskyplugin is not something implemented by an NPAPI plugin or webextension or similar?

Yes, autoskyplugin is an external implemented protocol. There is no dependencies on this call other than the redirection.

This isn't a security bug that needs to be hidden.

Sounds like a recent regression. We should check if it also changed in the 69 release as well as in ESR (and find a regression window)

Can I provide any other information to help the analysis of this topic? I can record videos or take screenshots if it would be helpful.

Firefox doesn't know the structure of "unknown" schemes. By default I don't think we're treating them as heirarchical, we'd treat them as "flat" like data: and blob:. Have you tried a policy of just autoskyplugin: ?

I haven't tried yet, but since we applied our CSP rules using "autoskyplugin://" everything was working fine. I'll update the policy to use only the colon ponctuation on our development environment and will update you.

I have changed the CSP rule to use "autoskyplugin:" on the frame-src category and is still getting blocked by the browser. Additionally, when the new rule was applied, it also stopped working on Google Chrome too.

OBS: I've tried with different specifications, like "autoskyplugin:*", "autoskyplugin*", "autoskyplugin:", "autoskyplugin". All of these were blocked by the browser (Firefox).

I have tested on the Firefox ESR 67.0v and can confirm that with the policy set as "autoskyplugin://" the iframe is being rendered and the external protocol is being called.

External protocol allowed:
data:text/html,<meta http-equiv="Content-security-policy" content="frame-src mailto:;"><iframe src="mailto:foo@bar.com"></iframe>

External protocol blocked:
data:text/html,<meta http-equiv="Content-security-policy" content="frame-src mailto://;"><iframe src="mailto:foo@bar.com"></iframe>
data:text/html,<meta http-equiv="Content-security-policy" content="frame-src mailto:*;"><iframe src="mailto:foo@bar.com"></iframe>
data:text/html,<meta http-equiv="Content-security-policy" content="frame-src mailto://*;"><iframe src="mailto:foo@bar.com"></iframe>

Comment 10 experimentally matches my interpretation of the spec, and what I said in comment 6.

Your comment 7 and comment 8 are mystifying given my understanding. Do you have a public example we can debug? If your work site is private can you create a tiny example like my data: urls above? (also, what is autoskyplugin:? do you get the same behavior with other protocols?)

"autoskyplugin:" is an external protocol implemented on Windows machines by one of our company softwares that receives some parameters from the browser to execute commands locally.

When we were implementing the CSP rules on the web application that send this parameters through the iframe "autoskyplugin://SOMEPATH", both Chrome and Firefox were allowing the request with the rule "frame-src 'self' autoskyplugin://*;" (even Firefox before v68 update).

After your update saying that firefox only allow the format "autoskyplugin:", I have now set on my CSP rule the following:
"frame-src 'self' autoskyplugin://* autoskyplugin:;". With that rule Firefox is accepting the request because of the last item, and Chrome is also accepting the request because of the first rule configured.

Now both browsers are allowing the request to be made.

On my side, this case can be closed. Thank you for your explanation and attention on this problem.

Based on the previous comments, should we file a bug against chrome to accept the protocol: version, and/or get the spec updated and add support for protocol://* and/or protocol:* ? This seems like something that's just going to keep catching people out otherwise.

I think that the way Chrome support both <code>protocol:</code> and <code>protocol://*</code> makes it easier to people misunderstand the correct way to configure the rules, and the is stuff on the web (stackoverflow questions and blog posts) that show examples of the <code>protocol://*</code> implementation. Looking at this right now I don't think that this is a problem for Firefox, but clearly updating the specification to also allow the <code>protocol://*</code> implementation would reduce the amount of people getting caught by this situation.

We agree. we should make sure the spec is clear on that. We have a test in our code that purports to demonstrate this syntax working exactly like this so now we need to figure out why our test didn't catch the regression

If you need any information from me I'm totally available to help.

To sum it up, Firefox should support both

• protocoll:
• protocoll://*

We should fix that - putting in the backlog for now though.

Assuming I understood right, managed to track the regressor for this issue.

• Pushlog URL
• last good build_date: 2019-07-10;
• first bad build_date: 2019-07-11;
• potential regressor: 1388015.

(In reply to Cristian Fogel, QA [:cfogel] from comment #18)

Assuming I understood right, managed to track the regressor for this issue.

• Pushlog URL
• last good build_date: 2019-07-10;
• first bad build_date: 2019-07-11;
• potential regressor: 1388015.

Could you please take a look?

Can confirm, Bug 1388015 did regress this.
The Patch removed us skipping checking the Port & Folder checks if we have " * " in the Host.
So in the case of "scheme://* " this would fail now.

A quick debug with the example from Comment 10 confirms permitsPort fails in getting the port for the external handler's Uri, fails and thus blocks the load.

https://hg.mozilla.org/mozilla-central/rev/297d6ec7c8b4