Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send "null" Origin header on cross-origin .onion requests #1351

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions fetch.bs
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,9 @@ urlPrefix:https://w3c.github.io/hr-time/#;spec:hr-time
"href": "https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram",
"publisher": "IETF",
"title": "Using QUIC Datagrams with HTTP/3"
},
"ONION": {
"aliasOf": "RFC7686"
}
}
</pre>
Expand Down Expand Up @@ -2820,6 +2823,11 @@ given a <a for=/>request</a> <var>request</var>, run these steps:
<li><p>Let <var>serializedOrigin</var> be the result of <a>byte-serializing a request origin</a>
with <var>request</var>.

<li><p>If <var>request</var>'s <a for=request>current URL</a>'s <a for=url>origin</a>'s
<a for=origin>host</a> ends with "<code>.onion</code>" or "<code>.onion.</code>", and
is not <a>same origin</a> with <var>request</var>'s <a for=request>origin</a>, then set
<var>serializedOrigin</var> to `<code>null</code>`. [[ONION]]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to "byte-serializing a request origin" we'll also end up with null if they are same origin but there's a cross-origin redirect in between. Ideally we'd test that, but I guess .onion will be hard to test.

Copy link
Author

@fmarier fmarier Nov 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've got these two no-cors manual test cases on my test page (you can also see it at http://fmarier.com/referrer/onion.html though it's meant to run from a .onion) :

  • example.onion --POST--> example.onion --307--> example.com
  • example.onion --POST--> example.com --307--> example.onion

For the first one, both Brave and Tor Browser send a null origin (and omit the referrer for that matter).

For the second one, however, Brave sends a null origin but the Tor browser sends the full Origin in that case.

Is a null Origin the desired behavior in both cases or just in the first one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the examples, what's the starting origin? As long as you are same-origin I would expect a referrer to be included, but once you've gone cross-origin once, it should no longer be possible.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The starting origin in all cases is example.onion. It issues two 307 redirects.

In the first example, it goes from example.onion to example.onion/anotherpage before ending on example.com.

In the second example, it goes from example.onion to example.com before ending on example.onion/anotherpage.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the user navigates to the starting origin? I guess then the scenarios would work. (Typically with fetching there's a starting document with some kind of authority and that would do the fetching, which could then result in a redirect. The initial 307 threw me off.)

Assuming the user does the navigation I'd expect:

  1. example.onion 307 to example.onion (Origin could be included here, e.g., in case of a POST); example.onion 307 to example.com (it would be null here)
  2. example.onion 307 to example.com (it would be null here); example.com to example.onion (it would continue to be null here, as it's been tainted by example.com)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the user navigates to the starting origin?

Yes, that's correct. However, I just realized that I made a mistake in my description of the test cases, which probably threw you off.

What I meant was:

  1. Navigate to example.onion/index.html.
  2. Submit form (POST) to example.onion/another.html.
  3. example.onion/another.html is a 307 redirect to example.com.
  4. You end up on example.com with a null Origin header.

The second test case is:

  1. Navigate to example.onion/index.html.
  2. Submit form (POST) to example.com.
  3. example.com is a 307 redirect to example.onion/another.html.
  4. You end up on example.onion/another.html with a null Origin header.

I had the same expectations as you (regarding the example.com tainting due to the redirect) and that's what I implemented in Brave, but Tor Browser returns an Origin of example.onion in the second case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like a pretty serious bug. @KershawChang @valenting ^^

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've filed bug 1742784 for this.


<li><p>If <var>request</var>'s <a for=request>response tainting</a> is "<code>cors</code>" or
<var>request</var>'s <a for=request>mode</a> is "<code>websocket</code>", then
<a for="header list">append</a> (`<code>Origin</code>`, <var>serializedOrigin</var>) to
Expand Down