Navigation algorithm consults filtered header list

[domenic]

See discussion in #8686 (comment). I'm not sure I understand this perfectly but I think the issue is: whenever the navigation algorithm looks at a response, it actually is looking at the filtered response. This is not good because the filtered response is missing lots of headers.

I'm not sure whether this is redirect-specific or general.

#8686 fixes one instance of this. But we should probably do a more comprehensive fix, and perhaps revert that.

Ideas for comprehensive fixes:

• Audit every time we look at a response in the navigate algorithm and make sure the filtering doesn't cause problems. If it does, reach into the unsafe response.
• Stop filtering responses, at the Fetch level, whenever mode = "navigate".
• In the HTML level, immediately pull out the unsafe response early in the navigate fetching algorithms, and always operate on that

@annevk, can you suggest a strategy? I'd be happy to work on PRs to implement it, I just am a bit out of my depth.

[annevk]

I think using a basic filtered response for navigation responses is the way to go.

---

Assume a browser architecture whereby there is a Browser process managing UI and navigations and zero or more Website processes responsible for agent clusters. Ideally most of the navigation, including redirect handling is handled by the Browser process and only at the end of that a decision is made to allocate a Website process for whatever authority the navigated to URL has.

With such an architecture the final response will not have have access to the redirect responses and it is evidently same-origin with its own response so any kind of filtering is mostly in vain, but filtering out HTTP cookies still seems valuable. (Now to be clear, this assumes a kind of filtering that's currently not implemented. In most implementations the filters are not robust against process-level attacks, though perhaps for HTTP cookies some are.)

I think there is a future where we could be more ambitious about filtering. E.g., essentially safelist the headers we know the navigate algorithm needs and block everything else. It's similar to opaque and poking select holes through it, but makes it much more clear to implementers and reviewers what the holes are. But you could essentially only test it through a Spectre attack so perhaps that's more of a "best in class" achievement for implementations to aim for and not something to define in the specification.

(@arturjanc these kind of musings prolly interest you.)

[domenic]

So is that the "audit and reach in" option from my list?

[annevk]

No, if we change Fetch to return a basic filtered response for navigations HTML doesn't need any changes because it doesn't inspect Set-Cookie headers. (A basic filtered response only filters out Set-Cookie and Set-Cookie2 headers.)

Everything below that was rationale for why that would be okay and how we could improve upon it, but also why that improvement wouldn't be black-box-distinguishable and therefore somewhat questionable as a time investment.

[domenic]

Got it. So the issue is that although the initial response's response tainting mode is "basic", step 7 of HTTP fetch doesn't currently do the right thing:

Set response to an opaque-redirect filtered response whose internal response is actualResponse. If request’s mode is "navigate", then set fetchParams’s controller’s next manual redirect steps to run HTTP-redirect fetch given fetchParams and response.

It should set it to a basic filtered response if mode = navigate. I'll give it a shot.