1671782 - CORS bloking a request to https://xn--b1afaypcij.xn--p1acf from an extension («Access-Control-Allow-Origin does not match «https://переслов.рус». But they are the same.)

Status: RESOLVED INCOMPLETE

(Core :: DOM: Security, defect)

Description

[manuka]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36

Steps to reproduce:

My extension makes request to https://переслов.рус while user is browsing on some other domain name.

My firefox version is 81.0.2 (32-bit)

Actual results:

In my console I see:

Запрос из постороннего источника заблокирован: Политика одного источника запрещает чтение удаленного ресурса на https://xn--b1afaypcij.xn--p1acf/api/v1/user. (Причина: заголовок CORS «Access-Control-Allow-Origin» не совпадает с «https://переслов.рус»).

translation:
The request from unknown source is blocked: One source policy denise reading from remote resource at https://xn--b1afaypcij.xn--p1acf/api/v1/user. (Reason: CORS header «Access-Control-Allow-Origin» does not match «https://переслов.рус»).

Expected results:

My http request should have not been blocked since https://xn--b1afaypcij.xn--p1acf is just a punycoded https://переслов.рус

That is they are the same.

Comment 1

[manuka]

Mind you, in my extension manifest.json I have both urls in "permissons":

"permissions": [
        "*://переслов.рус/*",
        "*://xn--b1afaypcij.xn--p1acf/*"
]

still this doesn't help

Comment 2

[manuka]

Sorry * didn't print. Here the actual permissions in my manifest.json
"permissions": [
"://переслов.рус/",
"://xn--b1afaypcij.xn--p1acf/"
]

Comment 3

[manuka]

Damn, it's this forum removes them! :) there are * at the beginning and the end of all the URLs

Comment 4

[Daniel Veditz [:dveditz]]

It's Markdown -- you can escape things with "backticks" (`) for a quoted string, or 3 on a line by itself to escape a block. I fixed comment 1 for you.

Comment 5

[Daniel Veditz [:dveditz]]

How does your extension make the requests? If they are made from a "content script" on the other domain then it is as if that domain made the request, and the CORS headers must specify the domain your script is in. But then the error would be different, wouldn't it? But if you made the request from a background script it should have gone through without CORS checks to an allowed host.

The manifest permissions aren't the problem here, in any case: You'd get a different error about the request being blocked before the request was even made. CORS errors are only given after the request.

Do you have more network information you can share, from the Network Tab of DevTools console, or the browser console? It would help to see the request headers and the response headers.

Comment 6

[Daniel Veditz [:dveditz]]

Internally all host comparisons should be done using the Punycode version of the name since that is the actual registered domain. The non-punycode version in the error message is converted just for readability.

Comment 7

[manuka]

How does your extension make the requests?
I do all remote request in the background script and all the handling of the XHR object event is done there.

Do you have more network information you can share, from the Network Tab of DevTools console, or the browser console?
I've tried to copy the logs but Hm.. I can't reproduce the error.

I mean it was there, I've copied the text of the error in the opening post, you can see it there. But now I can't reproduce it... How can this be? I've not updated or changed anything in my setup, nor firefox nor my extension.....

I'm stuck. What should I do now? What if the bug appears again?

Comment 8

[manuka]

How does your extension make the requests?
I do all remote request in the background script and all the handling of the XHR object event is done there.

Mind you, this bug was occurring for several days in a row. So it's not a "one off" thing.

Comment 9

[ben.geels019]

Attachment: Screenshot of request Incorrectly Blocked By CORs Policy

Comment 10

[ben.geels019]

Attachment: Obfuscated .har file.

Comment 11

[ben.geels019]

I believe I'm seeing something similar to this. The gist of my setup is.

• [Blue] - Web Application Server
• [Red] - Remote Server Hosting API
• [Yellow] - Authentication server.

The web application server retrieves data from the api server via fetch calls. Both servers are protected by the authentication server. When the web app makes a request to the api server it receives a 302 redirecting to the auth server. ( At this point it would normally do a bit of a handshake then retrieve the results. ).

However, in the debugger you see that the request is blocked b/c Access-Control-Allow-Origin does not match the Origin. The values do match exactly though. This does work in chrome, almost works in safari ( everything but the last post in the auth handshake ), haven't had a chance to test edge yet.

Debugger Screenshot

I also included an .har file of the requests. I had to obfuscate the data but hopefully it's still helpful.

Comment 12

[ben.geels019]

And... I didn't realize I was running 78.4.0esr on my Ubuntu 20.04 machine. After removing the snap installed version of firefox and reinstalling with apt I'm no longer seeing this behavior in version 82.

Comment 13

[Daniel Veditz [:dveditz]]

ben: is your problem involving an extension? If not please file a separate bug on it if it comes back. Is your problem involving IDNA/punycode host names? if not please file this as a separate problem. Since the problem we're investigating here involves potential IDNA/punycode mismatches, evidence that blanks out the hostnames involved will not help us diagnose anything.