1535380 - force inherit principals may confuse CookieSettings based cookie permission checks

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[(no longer active)]

For the bug STR, see https://bugzilla.mozilla.org/show_bug.cgi?id=1530132#c19.

Intermittently we end up with a cookie from demdex.net. Looking at the log that seems to come from here:

[Parent 21688: Main Thread]: D/AntiTracking Computing whether channel 0x7f85488e8040 has access to URI https://mscom.demdex.net/event?_ts=1552582930537
[Parent 21688: Main Thread]: D/AntiTracking Our loadInfo lacks a top-level principal, use the loadInfo's loading principal instead
[Parent 21688: Main Thread]: D/AntiTracking CheckCookiePermissionForPrincipal() returned a non-default access code (1) for channel's principal, returning success

We return true from here: https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/toolkit/components/antitracking/AntiTrackingCommon.cpp#1355. This check ends up doing the wrong thing: https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/toolkit/components/antitracking/AntiTrackingCommon.cpp#170.

Here the channel final URI is https://mscom.demdex.net/event?_ts=1552582930537, but the principal codebase URI is https://www.microsoft.com/library/svy/broker-config.js?1552582930481. I wondered why this is, so I looked into what GetChannelResultPrincipal() was doing, and the answer is that the channel is a force-inherit channel so the principal is being inherited from the loadinfo.

This tells me that using the principal here may be a mistake, since it may cause us to look up the cookie permission for an unrelated origin.

What do you think, Andrea?

(Not quite sure if this is a regression from bug 1525245 or not... Marking it as such for now.)

Comment 1

[Andrea Marchesini [:baku]]

I would like to reproduce this issue but I cannot. Do you know when SEC_FORCE_INHERIT_PRINCIPAL is set for that request?

There are only a few places where set that flag. https://mscom.demdex.net/event?_ts=1552582930537 is an image and in theory, we should not have that channel flag for images. We set it only if the src is loaded by a HTMLObjectElement/HTMLEmbedElement, but not for CORS requests.

Are able to reproduce it easily? Can you write a small test? If you can give me more data, I can work on it.

Comment 2

[(no longer active)]

I didn't investigate how we get the force principal case, maybe it's not through the SEC_FORCE_INHERIT_PRINCIPAL flag... Not 100% sure.

I can reproduce ~50% of the time in an opt build on Linux. Was https://mscom.demdex.net/event?_ts=xxx fetched as an image for you? That's an interesting difference, for me it's a POST XHR... (Note that if you just click on the URL you'll receive a 1x1 pixel, but if you look at the network monitor when loading microsoft.com, you'll see that request being submitted as a POST XHR with response type application/json;charset=utf-8 (for me at least.)

I don't know how to write a test case for it yet, since I haven't investigated it further. Let me know if you want me to, but it will be after next week. (Please needinfo me if you want me to investigate, thanks!)

Comment 3

[(no longer active)]

BTW for reproducing I just followed the original STR of bug 1525245 in a new profile. I got the information in comment 0 so far from turning on MOZ_LOG=AntiTracking:5 + some printf debugging.

Comment 4

[Oana Botisan, Desktop QA]

I managed to reproduce this issue on Windows 10 x64 using Firefox 67.0b3 and Firefox 66.0.

Another thing that I will like to mention is that on the profile that this issue is reproducing on, no matter how many times you clear all the cookies, the issue is still reproducing, until you open the profile with another version of Firefox (older or newer).

The good news is that if you update your Firefox, the issue is not reproducing anymore as far as I can tell. I thought this info might help you.

Comment 5

[(no longer active)]

Did you try this out, Andrea?

Comment 6

[Andrea Marchesini [:baku]]

no luck. I tried to reproduce it for a while, but nothing, I don't see that nsIChannel. Could it be a geolocation thing?
I also tried to use a user-agent switcher, but it didn't help.

Comment 7

[(no longer active)]

Yeah it could be.