firstPartyDomain not set on top-level domain URLs

RESOLVED FIXED in Firefox 68

Status

()

defect
P2
normal
RESOLVED FIXED
5 months ago
4 months ago

People

(Reporter: acat, Assigned: acat)

Tracking

(Blocks 1 bug)

Trunk
mozilla68
Desktop
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

(Whiteboard: [tor 24622][domsecurity-active])

Attachments

(1 attachment, 1 obsolete attachment)

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.

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?

OS: Unspecified → All
Hardware: Unspecified → Desktop
Version: 60 Branch → Trunk

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

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.

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.

Flags: needinfo?(tanvi)
Component: Untriaged → DOM: Security
Product: Firefox → Core

...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.

Redirecting to baku.

Flags: needinfo?(tanvi) → needinfo?(amarchesini)

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

Flags: needinfo?(amarchesini)
Whiteboard: [tor 24622]
Attachment #9057008 - Attachment is obsolete: true

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.

Assignee: nobody → acat
Priority: -- → P2
Whiteboard: [tor 24622] → [tor 24622][domsecurity-active]
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: checkin-needed

Pushed by opoprus@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f0ae73dd90f7
Set firstPartyDomain to public suffix if getBaseDomain fails. r=baku

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Alex, thank you for fixing this!

You need to log in before you can comment on or make changes to this bug.