[tor-bugs] #32865 [- Select a component]: Setting Origin: null header still breaks CORS in Tor Browser 9.5

[Tor Bug Tracker & Wiki]

#32865: Setting Origin: null header still breaks CORS in Tor Browser 9.5
--------------------------------------+--------------------
     Reporter:  micahlee              |      Owner:  (none)
         Type:  defect                |     Status:  new
     Priority:  Medium                |  Milestone:
    Component:  - Select a component  |    Version:
     Severity:  Normal                |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |   Reviewer:
      Sponsor:                        |
--------------------------------------+--------------------
 I'm working on creating an onion service version of theintercept.com using
 Alec Muffet's EOTK (https://github.com/alecmuffett/eotk) and running into
 an issue with CORS that lead me to #32255. The patch that fixed that issue
 doesn't totally solve the Tor Browser CORS problems.

 Specifically, embedding documents from DocumentCloud works in Tor Browser
 9.5 on the clearnet site, but breaks when viewing my test onion site. Here
 is an example document: https://theintercept.com/document/2019/05/08/ron-
 wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-
 protest-surveillance/

 This page makes a XHR request to
 `https://www.documentcloud.org/api/documents/5993383-Ron-Wyden-s-Letter-
 to-Private-Intelligence-Firm.json` with the following relevant request
 headers:

 {{{
 Origin: https://theintercept.com
 Referer: https://theintercept.com/
 }}}

 And the response has these relevant headers:

 {{{
 access-control-allow-credentials: true
 access-control-allow-headers: Accept,Authorization,Content-Length,Content-
 Type,Cookie
 access-control-allow-methods: OPTIONS, GET, POST, PUT, DELETE
 access-control-allow-origin: https://theintercept.com
 }}}

 The response body is JSON object that describes the document. This page
 ends up working fine. After loading that XHR request, it makes a series of
 other requests to assets.documentcloud.org, loading images for individual
 pages of the document to display.

 I've configured EOTK to basically run two onion services, one that proxies
 requests to theintercept.com
 (`ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion`) and one
 that proxies requests to documentcloud.org
 (`5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion`). (Note
 that both of these domains force HTTPS and use a self-signed certificate,
 so if you want to test them you'll need to accept the untrusted
 certificates.)

 Here is the onion service version of that page:
 https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08
 /ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-
 immigration-protest-surveillance/

 This page makes an XHR request to
 `https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion/api/documents/5993383
 -Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json` with the following
 relevant headers:

 {{{
 Origin: null
 }}}

 (Tor Browser is stripping the `Referer` header.)

 And the response includes these relevant headers:

 {{{
 Access-Control-Allow-Credentials: true
 Access-Control-Allow-Headers: Accept,Authorization,Content-Length,Content-
 Type,Cookie
 Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, DELETE
 Access-Control-Allow-Origin: null
 }}}

 The response body is blank, and this warning is in the Tor Browser
 console:

 {{{
 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the
 remote resource at
 https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqi…5993383-Ron-
 Wyden-s-Letter-to-Private-Intelligence-Firm.json. (Reason: CORS header
 ‘Access-Control-Allow-Origin’ does not match ‘null’).
 }}}

 Note that if I configure EOTK to only create an onion proxy for
 theintercept.com, and not for documentcloud.org, I get the same behavior.

 One possible solution would be to treat onion sites that load resources
 from other onion sites different than onion sites loading resources from
 clearnet sites. When it's onion -> onion, it could send the actual
 `Referer` and `Origin` headers, but when it's onion -> clearnet, it could
 strip the `Referer` header and send `Origin: null`, which is the current
 behavior.

 For example, if
 `https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08
 /ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-
 immigration-protest-surveillance/` makes a request to
 `https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion/api/documents/5993383
 -Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json`, it would send
 these headers:

 {{{
 Origin:
 https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion
 Referer:
 https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/
 }}}

 However if
 `https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08
 /ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-
 immigration-protest-surveillance/` makes a request to
 `https://www.documentcloud.org/api/documents/5993383-Ron-Wyden-s-Letter-
 to-Private-Intelligence-Firm.json`, it would send these headers:

 {{{
 Origin: null
 }}}

 But also, in the case of The Intercept's website, I don't think it's a
 problem to leak the domain name in the `Origin` header when making
 requests to DocumentCloud, and in fact it would be nicer to not have to
 use a separate documentcloud.com onion proxy at all. I believe it would
 "just work" if the `Origin` header were passed as expected. So, another
 possible solution would be if an onion site could somehow tell Tor Browser
 that it doesn't want the `Referer` or `Origin` headers to be modified,
 maybe using an http header or something?

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