1645683 - WebExtension redirect request to data: uri blocked

Status: NEW

(WebExtensions :: Request Handling, defect, P2)

Description

[Teun van Eijsden]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

In my WebExtension, i added code like this:

chrome.webRequest.onHeadersReceived.addListener(redirectRequest, {'types' ['script','stylesheet','font'], 'urls': ['://domain.com/']}, ['blocking']);
function redirectRequest(req) { return { redirectUrl: 'data:font/woff2;base64,d09GMgABAAAAA...'; }

This code DOES work for 'script' and 'stylesheet' but it gives his error for 'font':

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at data:font/woff2;base64,d09GMgABAAAAADUsAA4AAAAAgXwAA...

There is no CSP header on the HTML or the CSS file that references the font url.

This is probably related to bug 1434357

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Alexandra Martin]

Hi,

Thank you for submitting this bug report. Can you give an add-on in order to test for the problem? And also maybe a screenshot to better understand the issue?

Comment 3

[Teun van Eijsden]

Attachment: Bug1645683.xpi, use it on a site that uses google fonts, like avedictionary.com

Install this addon, enable logging to console for WebExtensions or open the "debugging" window for this WebExtension, surf to https://avedictionary.com/ or any other site that uses Google Fonts.

• Observe that one CSS is replaced by this WebExtension with a data: URI successfully
• Observe that the font is replaced by this WebExtension with a data: URI UNsuccessfully resulting in these errors:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at data:font/woff2;base64,d09GMgABAAAAAAzMAA4AAAAAGKQ....

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Mu4mxKKTU1Kg.woff2. (Reason: CORS request did not succeed).

downloadable font: download failed (font-family: "Roboto" style:normal weight:400 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Mu4mxKKTU1Kg.woff2

Comment 4

[Teun van Eijsden]

Attachment: Screenshot 2020-06-17 at 21.51.47.png

Comment 5

[Alexandra Martin]

Hi,

Thank you for the quick response. I was able to reproduce the described issue while testing on Windows 10 X 64 bit and Mac 10.14 with Nightly 79.0a1 (20200617215206), Beta 78.0b8 (20200616235426) and Release 77.0.1 (20200602222727).

Comment 6

[kernp25]

Maybe you know why it's not working?

Comment 7

[Teun van Eijsden]

(In reply to kernp25 from comment #6)

Maybe you know why it's not working?

No sorry. I briefly looked at toolkit/components/extensions/webrequest/WebRequest.jsm but found no reference to "font".

Comment 8

[Tomislav Jovanovic :zombie]

Can you find the regression range please?

Comment 9

[Alexandra Martin]

Attachment: bug 1645683 ffn 61.0a1 build 20180426220144.png

I managed to find a last good build from 2018-04-25 running on Nightly 61.0a1 (20180425220031) and a first bad build from 2018-04-26 running on Nightly 61.0a1 (20180426220144). Unfortunately Mozregression was giving several warnings and couldn't further bisect.

I've also attached a screenshot of how the Browser Console looks in the first bad build. If I can help with anything else please let me know.

Pushlog for first bad build: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e33e5049d9f35e16893f5ba4ec823f69f04972dd&tochange=63a0e2f626febb98d87d2543955ab99a653654ff

Comment 10

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Alexandra Martin from comment #9)

Pushlog for first bad build: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e33e5049d9f35e16893f5ba4ec823f69f04972dd&tochange=63a0e2f626febb98d87d2543955ab99a653654ff

Thanks for bisecting. The changeset within the provided pushlog that touches CORS is 1442551 which simply provides better console logging for CORS errors than what we used to have before, but the actual CORS error reported is the same.

I don't think that Bug 1434357 and the entire 'insecure redirect to data: URI prevention mechanism' is involved in the problem reported here, because that is orthogonal to CORS and also the reported error would be different.

Honza, can you help out? Any suggestions?

Comment 11

[Honza Bambas (:mayhemer)]

And isn't exactly the bug 1442551 the cause we now SEE that the resource is blocked? I can't see any change related to fonts in the pushlog. I believe this didn't work before either, we now just log it.

It could be something with the LOAD_ANONYMOUS flag we use for font loading, but hard to say. Need to debug this.

Comment 12

[Honza Bambas (:mayhemer)]

So, it more looks like we don't capture the other types of requests ('script','stylesheet'). Moving 'font' as the first produces the same behavior. Removing it shows we don't get any Bug1645683 request log in the addon inspection console.

Comment 13

[Honza Bambas (:mayhemer)]

Err.. no, didn't look at this right. We also intercept the css requests.

I think the cause is elsewhere:
https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/layout/style/FontPreloader.cpp#58
securityFlags = nsILoadInfo::SEC_REQUIRE_CORS_DATA_INHERITS;

which makes us go here:
https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/dom/security/nsContentSecurityManager.cpp#967
rv = DoCORSChecks(aChannel, loadInfo, aInAndOutListener);

And I think the '==' in nsContentSecurityManager::doContentSecurityCheck is a security bug.

Comment 14

[Honza Bambas (:mayhemer)]

To sum, I think we should block more and not less. This bug is actually reversed: we SHOULD block also for other resource types that require it and not just for fonts.

Comment 15

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Honza Bambas (:mayhemer) from comment #13)

And I think the '==' in nsContentSecurityManager::doContentSecurityCheck is a security bug.

Please note that we call GetSecurityMode().

Basti, to me the fonts should actually load correctly. Since you working on a similar problem, can you please take a look?

Comment 16

[Sebastian Streich [:sstreich]]

on it :)

Comment 17

[Sebastian Streich [:sstreich]]

Attachment: Bug 1645683 - Check Cors Redirect datahandling with nsContentSecurityManager r=ckerschb

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:sstreich, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 19

[Sebastian Streich [:sstreich]]

Updated the patches tests, once they are r+ this can land :)

Comment 20

[uBlock-user]

This affects XHRs in particular also when using uBlock Origin with neutered resources from the extension package. Will the fix address that too alongside the aformentioned font issue ?

Comment 21

[Sebastian Streich [:sstreich]]

If the issue is approx "some request -> extension-redirect to data uri -> cors blocked it" - then this might be adressed. Do you have a bug number for the uBlock Origin problem? I would like to look into this then :)

Comment 22

[uBlock-user]

I didn't file any bug, but the old one is at https://bugzilla.mozilla.org/show_bug.cgi?id=1434357