search

whatwg / fetch

Fetch Standard
https://fetch.spec.whatwg.org/
Other
2.1k stars 325 forks source link

Send "null" Origin headers on cross-origin requests from an RFC7686 address #1350

Open fmarier opened 2 years ago

fmarier commented 2 years ago

The special-use .onion domain name, defined in RFC7686, receives special treatment in the Tor browser and in Firefox: https://searchfox.org/mozilla-central/rev/6c8d325e61b0b445ed2e04899da38c3a4c266cba/netwerk/protocol/http/nsCORSListenerProxy.cpp#979-984

It seems like this behavior should be standardized since any browser could be setup to proxy traffic over the Tor SOCKS5 proxy.

I also filed an issue against the Referrer Policy spec to address the Referrer header.

annevk commented 2 years ago

Thanks for raising this. There's also #248 which we could address now I think (although I'm not familiar with the details).

fmarier commented 2 years ago

There's also #248 which we could address now I think (although I'm not familiar with the details).

Yeah, I'm not too sure exactly where that should be addressed in Fetch. I'm also not familiar with how it's implemented in Firefox.

annevk commented 2 years ago

cc @artines1 @ddragana

mikewest commented 2 years ago

If I understand the proposal correctly, this would have the effect of disabling meaningful access controls for resources that .onion pages wish to access (since any cross-origin response to a CORS-mode request would have to send headers that allowed any opaque origin to access the resource). That seems like a somewhat counterproductive restriction.

A weaker version of this proposal would apply the restriction to no-cors requests, but not to CORS requests (similar conceptually to the credentialless COEP mode). Is that direction worth exploring?

fmarier commented 2 years ago

If I understand the proposal correctly, this would have the effect of disabling meaningful access controls for resources that .onion pages wish to access.

That's a good point. It seems indeed like an unfortunate side-effect of the current implementation in Tor Browser.

My understanding of what Tor Browser is trying to protect here is an Onion service accidentally leaking its identity via linking to or embedding cross-origin resources. If we limited this new restriction to no-CORS requests, then the only case of accidental leakage I can think of would be Onion services using an anonymous CORS request in order to use subresource integrity with https://code.jquery.com/jquery-1.11.1.js for example. I think we could make a convincing case that the more typical CORS requests (e.g. those with credentials) are intentional and coordinated with the third-party (i.e. no accidental leakage).

fmarier commented 2 years ago

I'm happy to file implementation bugs and work on the tests, but before that, I'd like to know whether that's a change that Chrome and Firefox (others?) would be willing to make. (I would also be happy to work on upstreaming the Brave changes to Chromium.)

Is @mikewest 's suggestion (only touching no-cors) what folks think should be done? Is this something I should bring up at the next WebAppSec teleconf?

annevk commented 2 years ago

Some developers do seem to expect that CORS would include .onion domain details: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32865 (thanks @valenting for finding that!). But, having discussed this a bit with @tomrittervg it's not clear to me that's the way to go. Leaking .onion domains to other sites has these risks:

  1. It reveals the .onion domain exists. .onion domains are a lot like capability URLs and some are definitely meant to stay secret as I understand it.
  2. It reveals the user uses .onion domains. (I'm not sure this is a problem on its own, especially with newish state partitioning behavior.)

Coupled with the fact that depending on CORS is quite easy (e.g., using a cross-site library for a font), I don't think we want it to leak by default. Having said that, I could imagine supporting some kind of policy for this for .onion domains that self-declare in some manner that they are not secret. But it seems that should be a follow-up, if anything.

I'd additionally like to solicit feedback from those more closely involved with .onion. @sysrqb @alecmuffett perhaps you could comment as to whether this seems reasonable?

(Aside: I think it's also a bug in Tor Browser and possibly Firefox therefore that a `null` origin and credentials does not work. At least per https://fetch.spec.whatwg.org/#cors-check that is fine.)