[tbb-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:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-  |  Actual Points:
  regression, TorBrowserTeam201911R              |
Parent ID:                                       |         Points:  2
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by acat):

 * status:  assigned => needs_review
 * keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-regression,
     TorBrowserTeam201911 => tbb-9.0-issues, tbb-9.0.1-can, tbb-regression,
     TorBrowserTeam201911R


Comment:

 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?

 ---

 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.

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