origin-or-null definition and TAO processing

[yoavweiss]

I'm failing to find if and where origin-or-null is defined. The "null" case is also not addressed in the "timing allow check" processing model.

IIUC, we need to:

• Add a definition for origin-or-null. I'm not sure if the origin part should be a token or there are more specific syntax definitions at https://tools.ietf.org/html/rfc7230#appendix-B or elsewhere (CCing @reschke for his opinion)
• Point the origin comparison in the processing model to https://tools.ietf.org/html/rfc6454#section-5 as https://tools.ietf.org/html/rfc6454#section-4 doesn't really return a string.
• Add tests that make sure that origin comparison in TAO also works for non-standard ports, doesn't work for different schemes, etc.
• Add a null related condition in the processing model.

Thoughts?

[igrigorik]

origin-or-null is defined in Fetch: https://fetch.spec.whatwg.org/#origin-header. Related discussion in: #62 (comment)

[yoavweiss]

OK, cool. So we can just link to that definition. The rest of the points still stand.

[yoavweiss]

@marcoscaceres - It seems that a lot of my origin confusion here resulted from the fact that the links (which exist in the markup) are not shown. Are there known issues around Respec and links inside <pre>?

[marcoscaceres]

Generally there should be no issues, but it might be confusing the syntax highlighting if it’s inside a pre. I can have a look.

[yoavweiss]

Following a discussion on IRC with @annevk, I tend to think this will require larger Fetch integration than I initially thought:

• "null" handling should work for tainted or opaque origins
• In order to support that, we're better off relying on some version of Fetch's serializing a request origin, only we'll need an equivalent using the Document's origin. I'm not quite sure how that would work.
• We'd need tests for all of the above.

[annevk]

You'd invoke https://html.spec.whatwg.org/#ascii-serialisation-of-an-origin directly on document's origin (which is defined at https://dom.spec.whatwg.org/#concept-document-origin by the way).

The main problem I see with your current setup is that you have no notion of redirects so if A requests B which redirects to A, this would consider it same-origin, despite it leaking information about B. That seems bad.

[annevk]

It seems that a number of these things you can and should address today, either by fixing or adding issue markers, so implementers don't implement security vulnerabilities.

[yoavweiss]

You'd invoke https://html.spec.whatwg.org/#ascii-serialisation-of-an-origin directly on document's origin (which is defined at https://dom.spec.whatwg.org/#concept-document-origin by the way).

OK, so that's one missing piece that would cover opaque origins and is fairly easy to add.

The main problem I see with your current setup is that you have no notion of redirects so if A requests B which redirects to A, this would consider it same-origin, despite it leaking information about B. That seems bad.

Good point. AFAICT, fixing it would require a) RT to start using Fetch's Response objects rather than "resource" b) Fetch to propagate the "tainted" flag from Request to Response. I can definitely add an issue marker in the short term, but fixing it seems like it would fit well with the larger Fetch-based "rebase".

[annevk]

Thanks. Calling these issues out inline would already be a huge help, especially since not everyone has time to study the issue list in detail.

[yoavweiss]

@annevk Seems like the cross-origin redirect sandwich case is already covered by a WPT.

[annevk]

As far as I can tell resource-timing/resource_timing_cross_origin_redirect_chain.html doesn't test same-origin to cross-origin, but I'm not really familiar with the harness in use there.

[yoavweiss]

You're right. The chain is XO->XO->SO->SO (where TAO is set for the XO resources). I'll add a test for the SO->XO->SO chain

[toddreifsteck]

@yoavweiss Could you explain why fetch integration is 100% required? Can't we simply add a bit of verbage to monkey patch this in to RT 2? I may simply be naive. :-)

[toddreifsteck]

Pulling it back so we can discuss. Sorry if that causes any hassle. This one feels like it belongs in 2 from my sniff of it.

[marcoscaceres]

Generally speaking, if you can avoid monkey patching that's preferred - as when implementing, it means implementers can safely send things into the fetch machinery, which can be updated independently of this spec. The monkey patch risks getting out of date with the spec it is patching, meaning that a middle layer could end up being required for compat with this spec.

[yoavweiss]

#172 addresses some of the definitions here that don't require Fetch integration, and adds a note regarding the security concerns. A review of that as well as web-platform-tests/wpt#13518 would be appreciated. A previous comment covers the missing bits in Fetch and related to Fetch integration. Monkey-patching those here don't seem like a small feat, nor does that seem helpful to do outside the context of the wider Fetch integration.

So with that, I'll create a new issue that makes sure the above PRs land for L2, but bump this one back to L3, for the larger scope Fetch integration.