Bug 260284
| Summary: | Incorrect Sec-Fetch-Site values on sandboxed iframes | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jerry Zhang <jerryzz> |
| Component: | Frames | Assignee: | youenn fablet <youennf> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | achristensen, annevk, bfulgham, cdumez, jerryzz, pgriffis, vincentlee, webkit-bug-importer, wilander, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 16 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=256472 | ||
Jerry Zhang
The Sec-Fetch-Site header is supposed to reflect the relationship between the origin of request's initiator and the origin of it's target. (https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header)
However, the current behavior seems to be incorrect for sandboxed iframes where a same-origin url will result in a Sec-Fetch-Site header with value "cross-site". i.e.
Reproduction steps:
Visit https://polar-purrfect-pangolin.glitch.me/sandboxediframe.html which contains:
<iframe src="https://polar-purrfect-pangolin.glitch.me/" sandbox></iframe>
Expected behavior:
The Sec-Fetch-Site header of the sandboxed iframe request has value "same-origin"
Actual behavior:
The Sec-Fetch-Site header of the sandboxed iframe request has value "cross-site"
https://bugs.webkit.org/show_bug.cgi?id=256472 may be related.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/114340186>
Vincent Lee
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.
This appears to still be a bug in Safari 17.5
Vincent Lee
Actually, on further reading of the spec, I'm Chrome and FF might be the ones with the bug here.
Sandboxing an iframe without `allow-same-origin` means the origin becomes opaque, and if I'm reading the language correctly for Sec-Fetch-Site, the algorithm for setting the header asserts that the request is from a "potentially trustworthy origin", which an opaque origin is not.
youenn fablet
I think Chrome and FF are correct here. The env origin is the top level frame.
youenn fablet
Pull request: https://github.com/WebKit/WebKit/pull/29450
EWS
Committed 280065@main (deeefb52b7fd): <https://commits.webkit.org/280065@main>
Reviewed commits have been landed. Closing PR #29450 and removing active labels.