256472 2023-05-08 09:46:27 -0700 Incorrect Sec-Fetch-Site values on iframes 2024-04-18 05:29:13 -0700 1 1 1 Unclassified WebKit Frames Safari 16 Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=260284 InRadar P2 Major --- 1 niemczura webkit-unassigned achristensen annevk bfulgham cdumez jerryzz pgriffis vincentlee webkit-bug-importer wilander youennf oldest_to_newest 1953725 0 niemczura 2023-05-08 09:46:27 -0700 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. 1954099 1 466295 pgriffis 2023-05-09 12:06:04 -0700 Created attachment 466295 fetch-metadata-iframe-no-referrer-test.patch Attached is a test case for this. Will look into it further. 1955446 2 webkit-bug-importer 2023-05-15 09:47:19 -0700 <rdar://problem/109358563> 1955746 3 pgriffis 2023-05-16 13:17:17 -0700 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. 1956456 4 annevk 2023-05-19 06:30:29 -0700 Why would user-initiated matter here? 1956560 5 pgriffis 2023-05-19 12:21:10 -0700 (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. 1958385 6 annevk 2023-05-27 05:34:25 -0700 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. 1971574 7 jerryzz 2023-08-16 13:08:27 -0700 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 1971966 8 pgriffis 2023-08-17 18:43:19 -0700 (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 1972925 9 annevk 2023-08-23 00:47:12 -0700 Patrick, but none of that applies to a nested document navigation, right? 2024481 10 vincentlee 2024-03-28 09:55:23 -0700 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. 2029432 11 ews-feeder 2024-04-18 05:29:10 -0700 Committed 277662@main (ab5d20c0ff15): <https://commits.webkit.org/277662@main> Reviewed commits have been landed. Closing PR #27350 and removing active labels. 466295 2023-05-09 12:06:04 -0700 2023-05-09 12:06:04 -0700 fetch-metadata-iframe-no-referrer-test.patch test.patch text/plain 1331 pgriffis ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2h0dHAvd3B0L2ZldGNoL2ZldGNoLW1ldGFkYXRhLWlm cmFtZS1uby1yZWZlcnJlci5odG1sIGIvTGF5b3V0VGVzdHMvaHR0cC93cHQvZmV0Y2gvZmV0Y2gt bWV0YWRhdGEtaWZyYW1lLW5vLXJlZmVycmVyLmh0bWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5k ZXggMDAwMDAwMDAwMDAwLi4yNmUyNWMzN2Y0NzgKLS0tIC9kZXYvbnVsbAorKysgYi9MYXlvdXRU ZXN0cy9odHRwL3dwdC9mZXRjaC9mZXRjaC1tZXRhZGF0YS1pZnJhbWUtbm8tcmVmZXJyZXIuaHRt bApAQCAtMCwwICsxLDE1IEBACis8c2NyaXB0PgorICAgIGlmICh3aW5kb3cudGVzdFJ1bm5lcikg eworICAgICAgICB0ZXN0UnVubmVyLmR1bXBBc1RleHQoKTsKKyAgICAgICAgdGVzdFJ1bm5lci5k dW1wQ2hpbGRGcmFtZXNBc1RleHQoKTsKKyAgICAgICAgdGVzdFJ1bm5lci53YWl0VW50aWxEb25l KCk7CisgICAgfQorCisgICAgZnVuY3Rpb24gaWZyYW1lRG9uZSgpCisgICAgeyAgICAKKyAgICAg ICAgaWYgKHdpbmRvdy50ZXN0UnVubmVyKQorICAgICAgICAgICAgdGVzdFJ1bm5lci5ub3RpZnlE b25lKCk7CisgICAgfQorCisgICAgPC9zY3JpcHQ+CisgICAgPGlmcmFtZSBvbmxvYWQ9ImlmcmFt ZURvbmUoKSIgcmVmZXJyZXJwb2xpY3k9Im5vLXJlZmVycmVyIiBzcmM9Ii9XZWJLaXQvZmV0Y2gv cmVzb3VyY2VzL2VjaG8tZmV0Y2gtbWV0YWRhdGEucHkiPjwvaWZyYW1lPgpkaWZmIC0tZ2l0IGEv TGF5b3V0VGVzdHMvaHR0cC93cHQvZmV0Y2gvcmVzb3VyY2VzL2VjaG8tZmV0Y2gtbWV0YWRhdGEu cHkgYi9MYXlvdXRUZXN0cy9odHRwL3dwdC9mZXRjaC9yZXNvdXJjZXMvZWNoby1mZXRjaC1tZXRh ZGF0YS5weQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAuLmE3MWRjMzhm ODU3MwotLS0gL2Rldi9udWxsCisrKyBiL0xheW91dFRlc3RzL2h0dHAvd3B0L2ZldGNoL3Jlc291 cmNlcy9lY2hvLWZldGNoLW1ldGFkYXRhLnB5CkBAIC0wLDAgKzEsOCBAQAorIyEvdXNyL2Jpbi9l bnYgcHl0aG9uMworCitkZWYgbWFpbihyZXF1ZXN0LCByZXNwb25zZSk6CisgICAgcmVzcG9uc2Uu d3JpdGVyLndyaXRlX3N0YXR1cygyMDApCisgICAgcmVzcG9uc2Uud3JpdGVyLndyaXRlX2hlYWRl cihiIkNvbnRlbnQtVHlwZSIsIGIidGV4dC9wbGFpbiIpCisgICAgcmVzcG9uc2Uud3JpdGVyLmVu ZF9oZWFkZXJzKCkKKyAgICByZXNwb25zZS53cml0ZXIud3JpdGUoYidTZWMtRmV0Y2gtU2l0ZTog JyArIHJlcXVlc3QuaGVhZGVyc1snU2VjLUZldGNoLVNpdGUnXSkKKyAgICByZXNwb25zZS5jbG9z ZV9jb25uZWN0aW9uID0gVHJ1ZQo=