[tor-bugs] #32255 [Applications/Tor Browser]: Missing ORIGIN header breaks CORS in Tor Browser 9.0

[Tor Bug Tracker & Wiki]

#32255: Missing ORIGIN header breaks CORS in Tor Browser 9.0
-------------------------------------------------+-------------------------
 Reporter:  complexparadox                       |          Owner:  acat
     Type:  defect                               |         Status:  closed
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:  fixed
 Keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-  |  Actual Points:
  regression, TorBrowserTeam201911R, tbb-        |
  backport                                       |
Parent ID:                                       |         Points:  2
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by gk):

 * status:  needs_review => closed
 * keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-regression,
     TorBrowserTeam201911R =>
     tbb-9.0-issues, tbb-9.0.1-can, tbb-regression, TorBrowserTeam201911R,
     tbb-backport
 * resolution:   => fixed


Comment:

 Replying to [comment:20 acat]:
 > Replying to [comment:15 gk]:
 > > Hm,
 > > {{{
 > > +    if (!currentOrgin.EqualsIgnoreCase(origin.get()) &&
 > > +        StringEndsWith(potentialOnionHost,
 NS_LITERAL_CSTRING(".onion"))) {
 > > +      origin.Truncate();
 > > +    }
 > > +  }
 > > +
 > >    rv =
 http->SetRequestHeader(nsDependentCString(net::nsHttp::Origin), origin,
 false);
 > >    NS_ENSURE_SUCCESS(rv, rv);
 > > }}}
 > > and
 > > {{{
 > > +            if (!origin.EqualsIgnoreCase(currentOrigin.get())) {
 > > +                // Origin header is suppressed by .onion
 > > +                return;
 > > +            }
 > > +        }
 > >      }
 > >
 > >      rv = mRequestHead.SetHeader(nsHttp::Origin, origin, false /*
 merge */);
 > > }}}
 > > does not even seem to be the same behavior depending on whether the
 code takes the `nsHttpChannel` or the `nsCORSListenerProxy` path or am I
 missing something here?
 >
 > Do you mean that one truncates the origin and the other just  not sets
 it? Or that the 'is .onion' check is done differently in both cases?

 The former.

 > ---
 >
 > I checked with
 doublemixwcfx4wadeuvuygpxej5jpu7uleesh3yptopnbj5kshnlrid.onion and
 apparently they fixed it already, so we cannot tell if setting `Origin:
 null` would have fixed the original issue or not. But if we are going to
 keep the current behaviour, with .onion website being "privacy-sensitive
 context", I guess it's better to set it to null rather than removing the
 header and be more compliant with the spec.
 >
 > For esr68 I think this would do it: https://github.com/acatarineu/tor-
 browser/commit/32255. I can file a bugzilla issue for this.

 Please do. The patch looks good to me. Merged to `tor-
 browser-68.2.0esr-9.5-1` (commit
 f26fb9c17d71f3373c8ccb91ae74c438d9e13f80). Marking for possible backport.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32255#comment:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online