1542309 - firstPartyDomain not set on top-level domain URLs

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P2)

Description

[Alex Catarineu (Tor Browser dev)]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

1. Visit about:config and set privacy.firstparty.isolate to true.
2. Visit https://s3.amazonaws.com/anybucket/whatever.
3. Open Browser Console (Ctrl +Shift + J).
4. Check value of gBrowser.contentPrincipal.originAttributes.firstPartyDomain.

Actual results:

Value is empty.

Expected results:

Expecting value to be s3.amazonaws.com.

Comment 1

[Alex Catarineu (Tor Browser dev)]

Context:

With privacy.firstparty.isolate set to true, originAttributes.firstPartyDomain is empty for top-level domain URLS. For example: https://s3.amazonaws.com/anybucket/whatever.

Since Tor Browser relies on firstPartyDomain for circuit isolation, this means that all urls with top-level domains will share the same (catch-all) circuit.

This is the current implementation in OriginAttributes::SetFirstPartyDomain. Is this a bug, or is it the intended behavour? Would it be ok for firstPartyDomain to be the first-level domain = host on these cases (instead of empty), or are there reasons why this is not a good idea/possible?

Comment 2

[Tom Ritter [:tjr] (OOTO until mid-August)]

To be clear; this happens because s3.amazonaws.com is in the PSL as detailed here: https://trac.torproject.org/projects/tor/ticket/24622#comment:41

Comment 3

[Daniel Veditz [:dveditz]]

I think that's working as designed (for the PSL). You can't set cookies on ".com". By being in the PSL "s3.amazonaws.com" becomes equivalent to "com". That means foo.s3.amazon.com would be separate from bar.s3.amazon.com -- that's great if you're foo.github.io, but no so much if you don't have subdomains. Good for s3 though because then one bucket can't set cookies or storage and pollute independent users of it.

The first party isolation feature will have to take this into account. Although some entries on the PSL are virtual and the user would never visit (".com"), some are very real (s3.amazonaws.com). Without looking at the code I'm assuming you're using "getBaseDomain" from the eTLD service, sometimes referred to as "eTLD+1". That will be empty for entries in the PSL because there's no +1. The firstparty code could then look at and return getPublicSuffix instead. Without thinking too hard at the ramifications (please double check me!) I think that gives you what you want, and if for some reason s3 ever in the future sprouts subdomains they will still be different from this base.

Comment 4

[Daniel Veditz [:dveditz]]

Actually I'm suggesting Tor's circuit-making code dig deeper if the firstPartyDomain is blank. I worry a bit that there could be other users of originAttributes.firstPartyDomain who might use blank (or not-blank) as a proxy for checking whether something is a public suffix or not. Need to be careful here.

Comment 5

[Alex Catarineu (Tor Browser dev)]

...Good for s3 though because then one bucket can't set cookies or storage and pollute independent users of it.

Setting cookies doesn't work, but (local)storage does work. Not related to this bug I think, but just to make sure this is expected.

Actually I'm suggesting Tor's circuit-making code dig deeper if the firstPartyDomain is blank. I worry a bit that there could be other users of originAttributes.firstPartyDomain who might use blank (or not-blank) as a proxy for checking whether something is a public suffix or not. Need to be careful here.

I checked usages of firstPartyDomain and I think nobody relies on its emptyness to check whether something is a public suffix or not. Fixing it in a single place in caps/OriginAttributes.cpp I think would be preferable, if there are no security implications. Currently the circuit isolation code (JS/XPCOM extension) relies on nsiChannel.loadInfo.originAttributes.firstPartyDomain to isolate each request accordingly. If this is empty I think we might be able to get the request origin host from nsiChannel.loadInfo.loadingPrincipal, but not sure if this is always available and accurate.

Comment 6

[Tanvi Vyas[:tanvi]]

Redirecting to baku.

Comment 7

[Andrea Marchesini [:baku]]

I have nothing to add to comment 3. It seems that we already have a patch to uplift, right?

Comment 8

[Alex Catarineu (Tor Browser dev)]

Attachment: Bug 1542309 - Set firstPartyDomain to public suffix if getBaseDomain fails.

Comment 9

[Alex Catarineu (Tor Browser dev)]

Attachment: Bug 1542309 - Set firstPartyDomain to public suffix if getBaseDomain fails.

Right now the firstPartyDomain is not set when host is in the public suffix list. The patch fixes it by setting firstPartyDomain to eTLD.getPublicSuffix in these cases.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0ae73dd90f7
Set firstPartyDomain to public suffix if getBaseDomain fails. r=baku

Comment 11

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/f0ae73dd90f7

Comment 12

[Ethan Tseng [:ethan]]

Alex, thank you for fixing this!