Handling iframing via <embed> / <object> #37
Comments
Why "potentially"? It seems like |
|
s/potentially/This could be solved by I'm happy if this doesn't require any spec changes and all browsers will send the |
|
Is the initial mode for these no-cors then? Maybe we should fix that as that does seem like a footgun. E.g., maybe-nested-navigate or some such. |
Yes. See step 4.4 of https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element and step 3.4 of https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-embed-element-setup-steps. Neither specifies
I don't have a strong opinion about overloading |
|
A worry I have is that even if we expose "destination" many folks might not think of the |
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
|
My slight concern with adding another mode is that it would complicate writing policy logic for developers. For every request, developers generally need to inspect both As it stands, iframing by using So, given the choice of adding another mode and keeping this as-is, I'd prefer the latter. (Maybe we can even kill framing renderable documents via these two elements?) @mikewest, re:
The outcome of that discussion was that currently it's not possible to launder Given all this, I'm fine with the current behavior and so I'm inclined to close this bug. @mikewest WDYT? |
|
You're saying this would complicate policy, but your position would complicate policy (much more so, I think) for the scenario expressed in OP. |
|
The original scenario talks about deploying a policy for restricting cross-site navigations without also restricting subresource loads. This is a secondary use case for Fetch Metadata; I wouldn't want to complicate the necessary logic for the primary -- likely much more common -- use case of preventing cross-site subresource loads for this reason. So, on balance, I think adding another mode value wouldn't be a great trade-off here. |
|
Is there a document that lists anticipated policies and the logic required for them? That would help a lot in evaluating this. The explainer has some and from that it seems you would evaluate |
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <[email protected]>
Reviewed-by: Łukasz Anforowicz <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/master@{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <kinukochromium.org>
Reviewed-by: Łukasz Anforowicz <lukaszachromium.org>
Commit-Queue: Mike West <mkwstchromium.org>
Cr-Commit-Position: refs/heads/master{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
UltraBlame original commit: 7d3b0c03f936cc0fb5a532f740664b0517ec0cc9
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <kinukochromium.org>
Reviewed-by: Łukasz Anforowicz <lukaszachromium.org>
Commit-Queue: Mike West <mkwstchromium.org>
Cr-Commit-Position: refs/heads/master{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
UltraBlame original commit: 7d3b0c03f936cc0fb5a532f740664b0517ec0cc9
…rvice., a=testonly
Automatic update from web-platform-tests
Set `Sec-Fetch-Mode` from the network service.
In order to move `Sec-Fetch-Mode` into the network service to ensure
that it's consistently set every time `Sec-Fetch-Site` is set, this
patch does a few things:
1. Based on the conversation in [1] and [2], this patch extends
`network::mojom::RequestMode` to include two new values to
represent nested navigations and object/embed navigations as
distinct from main-frame navigations.
2. It introduces a new `network::IsNavigationRequestMode()` function
to replace direct comparisons to `kNavigate` in various parts of
the codebase.
3. It refactors `network::SetSecFetchSiteHeader()` into
`network::SetFetchMetadataHeaders()`. This creates a single entry
point from `URLLoader` to set all Fetch Metadata headers, and
fleshes out the `Sec-Fetch-Mode` header.
[1]: w3c/webappsec-fetch-metadata#37
[2]: whatwg/fetch#755
Bug: 972263, 990864
Change-Id: Icd20c7640d3d08ecb34a739f0203140fdcc195d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1780725
Reviewed-by: Kinuko Yasuda <kinukochromium.org>
Reviewed-by: Łukasz Anforowicz <lukaszachromium.org>
Commit-Queue: Mike West <mkwstchromium.org>
Cr-Commit-Position: refs/heads/master{#693517}
--
Mark appcache.tentative.https.sub.html as slow
--
wpt-commits: 4f6052ac7224c6bd0c859bea09d73f4a846920f8, d6b04f2d1e8a3268ab31b373ec0d14fa55829dc9
wpt-pr: 18838
UltraBlame original commit: 7d3b0c03f936cc0fb5a532f740664b0517ec0cc9
|
Similar to #45 I believe this can be closed. |
I agree. :) |
The value of
Sec-Fetch-Modeshould tell the server how its response will be used, specifically: if it isnavigateornested-navigatethen the server should expect the response will render, and if it's something else (e.g.no-corsorcors) it will be used as a resource.The problem is that the
<embed>and<object>tags can load both resources (plugins, images) and renderable documents. At the time of sending the request the browser does not know the MIME type of the response so cannot guarantee to the server that it will not treat the response as HTML.This can be a problem for developers who would like to restrict navigations (e.g. to mitigate the exploitation of XSS or as a server-side equivalent to
X-Frame-Options) without restricting subresource loads; in that case, the server will see ano-corsload and will not have enough information to be able to reject such requests. This could potentiality be solved bySec-Fetch-Destbut its status is not clear-cut. We should figure this out.Examples:
https://arturjanc.com/fetch-metadata-hackit/iframe-embed-test.html
https://arturjanc.com/fetch-metadata-hackit/iframe-object-test.html
The text was updated successfully, but these errors were encountered: