Bug 256472

Summary:

Incorrect Sec-Fetch-Site values on iframes

Product:

WebKit

Reporter:

Bartosz Niemczura <niemczura>

Component:

Frames

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Major

CC:

achristensen, annevk, bfulgham, cdumez, jerryzz, pgriffis, vincentlee, webkit-bug-importer, wilander, youennf

Priority:

Keywords:

InRadar

Version:

Safari 16

Hardware:

Unspecified

OS:

Unspecified

See Also:

https://bugs.webkit.org/show_bug.cgi?id=260284

Attachments:

Description	Flags
fetch-metadata-iframe-no-referrer-test.patch	none

Description Bartosz Niemczura 2023-05-08 09:46:27 PDT

Sec-Fetch-Site values are supposed to provide information about the relationship between a request initiator's origin and the origin of the requested resource (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site and https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header)

However, when the following iframe is included on the page, the value of the Sec-Fetch-Site header will be "none":

<iframe method="get" referrerpolicy="no-referrer" src="https://www.example.com"></iframe>

It appears to be due to referrer policy attribute. Setting it to no-referrer will cause Safari to send Sec-Fetch-Site header with "none" value regardless of the origin the iframe i.e. same-origin, same-site and cross-site frames would all have this header set to "none".

---

Reproduction steps:
1. Open any website, e.g. example.com
2. Open developer tools and paste the following code in the JS console:
```
const iframe = document.createElement('iframe');
iframe.src = 'https://www.example.com';
iframe.referrerPolicy = 'no-referrer';
iframe.method = 'get';
document.body.appendChild(iframe);
```
3. Inspect the request headers send on the iframe request.

Expected Outcome:
The Sec-Fetch-Site header is set to same-origin, same-site and cross-site, etc.

Actual Outcome:
The Sec-Fetch-Site header is set to none.

Comment 1 Patrick Griffis 2023-05-09 12:06:04 PDT

Created attachment 466295 [details]
fetch-metadata-iframe-no-referrer-test.patch

Attached is a test case for this. Will look into it further.

Comment 2 Radar WebKit Bug Importer 2023-05-15 09:47:19 PDT

<rdar://problem/109358563>

Comment 3 Patrick Griffis 2023-05-16 13:17:17 PDT

So the problem is pretty clear in that `CachedResourceLoader::computeFetchMetadataSite()` should not be using referrer information to calculate this.

I'm having a hard time finding information to detect if a navigation was "user-initiated" though.

All the APIs that seem interesting like:

- DocumentLoader::lastNavigationWasAppInitiated()
- Navigation::wasUserInitiated()
- LocalFrame::hasHadUserInteraction()

All return not useful values on macOS Safari.

Comment 4 Anne van Kesteren 2023-05-19 06:30:29 PDT

Why would user-initiated matter here?

Comment 5 Patrick Griffis 2023-05-19 12:21:10 PDT

(In reply to Anne van Kesteren from comment #4)
> Why would user-initiated matter here?

To quote MDN for example:

> none
>    This request is a user-originated operation. For example: entering a URL into the address bar, opening a bookmark, or dragging-and-dropping a file into the browser window.

Comment 6 Anne van Kesteren 2023-05-27 05:34:25 PDT

Patrick, two things:

1. Best not to look at MDN to figure out what to implement. https://w3c.github.io/webappsec-fetch-metadata/ is the relevant specification.
2. Looking at https://w3c.github.io/webappsec-fetch-metadata/#abstract-opdef-set-site step 4 and the explanation linked there makes it clear to me that when navigating a nested document "none" can never be correct. A user-initiated navigation as meant there would always involve a top-level navigation.

Comment 7 Jerry Zhang 2023-08-16 13:08:27 PDT

In addition to referrerpolicy, it seems the Sec-Fetch-Site behavior is also incorrect for sandboxed iframes: https://bugs.webkit.org/show_bug.cgi?id=260284

Comment 8 Patrick Griffis 2023-08-17 18:43:19 PDT

(In reply to Anne van Kesteren from comment #6)
> Patrick, two things:
> 
> 1. Best not to look at MDN to figure out what to implement.
> https://w3c.github.io/webappsec-fetch-metadata/ is the relevant
> specification.

The spec you linked says the exact same things: https://w3c.github.io/webappsec-fetch-metadata/#directly-user-initiated

Comment 9 Anne van Kesteren 2023-08-23 00:47:12 PDT

Patrick, but none of that applies to a nested document navigation, right?

Comment 10 Vincent Lee 2024-03-28 09:55:23 PDT

Hi, what's the status on this? We'd love to roll out serverside security checks for Safari based on the Sec-Fetch headers, but Sec-Fetch-Site not being correct is giving us pause. We've rolled out on all other browsers, so only Safari is left.

Comment 11 EWS 2024-04-18 05:29:10 PDT

Committed 277662@main (ab5d20c0ff15): <https://commits.webkit.org/277662@main>

Reviewed commits have been landed. Closing PR #27350 and removing active labels.