search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.11k stars 2.67k forks source link

Surprising secure context inheritance behavior for opened windows #6369

Open letitz opened 3 years ago

letitz commented 3 years ago

Context: https://github.com/w3c/webappsec-secure-contexts/issues/82#issuecomment-776096228

Now that w3c/webappsec-secure-contexts#84 has landed and the HTML spec speaks only in terms of creation URLs, I think the spec is incorrect in the following case:

This holds even though frame B inherits frame A's origin, which is not potentially trustworthy.

Note that in Chrome 88, frame B is a non-secure context. This behavior is also asserted by web platform tests.

All that to say, I do not think we can rely only on the creation URL of the document to make decisions in the face of local schemes that inherit their origin from another document.

annevk commented 3 years ago

There's an interesting corner case where we have an environment, but it's not associated with a global and such yet (i.e., it's not an environment settings object and therefore there's no origin to speak of). This is when we need to make checks for COOP/COEP and potentially other features that are relevant when instantiating something new.

It seems that about:blank is the corner case that could be trustworthy before, but should not be trustworthy after... However, when we navigate to about:blank we already have all the information so it shouldn't have to be a corner case that flips state.

That is to say that perhaps we should aim to remove the need for step 1 and 2 of https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy and handle these as part of environment creation instead. (There might be other callers of that algorithm that need vetting of their own, I'm not sure.)

cc @fred-wang

letitz commented 3 years ago

It seems that about:blank is the corner case that could be trustworthy before, but should not be trustworthy after...

I don't follow - before and after what?

That is to say that perhaps we should aim to remove the need for step 1 and 2 of https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy and handle these as part of environment creation instead.

That sounds reasonable.

annevk commented 3 years ago

In that before the construction of the global and origin we'd only have about:blank to go on, which would be considered secure, but after construction of those things the origin should be authoritative (it isn't currently, mostly do to missing this issue) which would flip it to insecure. However, rather than fixing it by looking at the origin and accepting this flipping state I'd rather we address the root cause of flipping.

fred-wang commented 3 years ago

Just removing part 1/2 will definitely be a breaking change in Chrome (it's covered by internal and wpt tests), I would need more time to read more carefully and understand the proposal (and what you mean by moving these somewhere else). cc'ing @mikewest

annevk commented 3 years ago

@fred-wang it would be great if you could enumerate all the other callers of that algorithm.

fred-wang commented 3 years ago

@fred-wang it would be great if you could enumerate all the other callers of that algorithm.

Work on https://bugs.chromium.org/p/chromium/issues/detail?id=1153336 is not complete yet but basically:

Note that call sites may add more restrictions to "is url potentially trustworthy" (e.g. restriction to a specific scheme which make data: and about: irrelevant in that case).

fred-wang commented 3 years ago

@fred-wang it would be great if you could enumerate all the other callers of that algorithm.

I started to do that in https://bugs.chromium.org/p/chromium/issues/detail?id=1158302 but sometimes it's not clear why Chromium relies on it and to which spec statement it corresponds. This is going to be huge effort...