"timing allow check" is not well defined in the context of NavTiming

w3c / navigation-timing

Navigation Timing

https://w3c.github.io/navigation-timing/

Other

116 stars 30 forks source link

"timing allow check" is not well defined in the context of NavTiming #104

Closed bzbarsky closed 5 years ago

bzbarsky commented 5 years ago

https://w3c.github.io/navigation-timing/#dom-performancenavigationtiming-unloadeventstart says:

If the previous document, and all HTTP redirects when navigating, pass the timing allow check algorithm...

But "timing allow check" as defined at https://w3c.github.io/resource-timing/#dfn-timing-allow-check is something that operates on "resources" (which are not really a defined concept, as far as I can tell). In any case, it assumes that a "resource" has a Request attached to it, which a document may well not have at all.

It's really not clear to me what behavior is supposed to be implemented here and why it doesn't lead to security bugs depending on what people decide to do with Timing-Allow-Origin headers in this nonsensical case...

yoavweiss commented 5 years ago

Thanks for pointing this out!

I think we have 2 cases where Navigation Timing references TAO:

For the previous document, it's not clear which response needs to provide TAO, and what origin will this TAO be tested against. Since exposing the information exposes something about the previous document, it's logical that it's the response to the previous document that should have provided TAO headers, and that they are evaluated against the origin of the current document.
For redirects, it's not clear which origin they should be evaluated against. Since exposing the information exposes something about the redirected hosts to the current document, it's logical that they will be evaluated against the origin of the current document.

Both these cases are not something we took into account when revising the timing allow check in resource timing. If folks agree that this is what that algorithm should do in those contexts, I'll figure out revisions to it. We'd also need to add tests.

annevk commented 5 years ago

There's also the case of there not being a previous document, but maybe there are redirects. (When the user initiates navigation.)

You'll need to change HTML's navigate algorithm basically to record the TAO header of the final response (that creates a document) somehow. And when navigating is initiated you need to create a log where you put the recorded header of the "source" document, if any, and of any redirects. And then when you create a new document (where you also record the final TAO header) you also do a check on the TAO header log to determine whether you have access (presumably whether the origin of the newly created document is listed in those logged TAO headers in some fashion).

And then you need to deal with various edge cases such as redirecting to blob or data URLs, or initiating navigation from those.

igrigorik commented 5 years ago

Based on discussion at the f2f..

Current text was introduced in https://github.com/w3c/navigation-timing/issues/53
Previous text did not rely on TAO and scoped unloadEvent{Start,End} and redirect timing and counts to same-origin only. Further, we believe the previous behavior was correct, TAO is not the right mechanism here.

Actions:

Revert #53 spec text and limit above attributes to same-origin
Update the tests (e.g. https://github.com/web-platform-tests/wpt/pull/15746) to capture right behavior
Verify current tests in WPT, file implementation bugs if necessary

annevk commented 5 years ago

Well, this will still need integration with HTML. You can't monkey patch navigation forever.