[Webkit-unassigned] [Bug 215356] New: same-site navigation within iframes is still referrerpolicy=origin when "Prevent cross-site tracking" enabled

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 10 22:20:32 PDT 2020


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

            Bug ID: 215356
           Summary: same-site navigation within iframes is still
                    referrerpolicy=origin when "Prevent cross-site
                    tracking" enabled
           Product: WebKit
           Version: Safari 13
          Hardware: iPhone / iPad
                OS: iOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Frames
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: diafygi at gmail.com

According to a recent Intelligent Tracking Prevention (ITP) blog post[1][2], "ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains." and "All cross-site document.referrers are downgraded to their origin. This matches the already downgraded cross-site referrer request headers."

[1]: https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/
[2]: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

However, it seems that within an iframe, when the parent source is cross-site, that same-site navigation is _also_ restricted to origin-only referrals. Is this intentional? It is unclear in the documentation that same-site navigation within an embedded iframe will have origin-only referrals.

Reproduction steps:

1. I have created a demo[3] with the parent daylightpirates.org, and embedded two iframes, one with a same-site origin (daylightpirates.org), and one with cross-site origin (gethttpsforfree.com).
2. For each I put a link that leads to a second page of the iframed origin (e.g. same-site) which then reports the request's Referer header.
3. When the link is clicked in the gethttpsforfree.com iframe, the referrer is limited to origin-only.

[3]: Proof of concept demo: https://daylightpirates.org/iframe-referrerpolicy-test

What should happen:

1. Same-site navigation, even withing an iframe, no matter if the parent is cross-site, should be treated as same-site navigation and full referrer headers should be available.

Why this breaks things:

1. There are many third party widgets, embedded surveys, and other tools that let the users submit a form through the widget.
2. Since third-party cookies are often disabled, the embedded iframe used same-site referrer headers to provide CSRF protection so that iframed forms could still not be submitted cross-site and cross-page (preventing XSS exploits).
3. Restricting to origin-only eliminates the XSS protection and strong CSRF protection from iframe form submission in widgets, surveys, etc.

So, if this was intentional, it would be enormously helpful to understand what specific third-party tracking behavior this prevents, and help with possible alternatives to CSRF within third-party iframed tools.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200811/b02df9f9/attachment.htm>


More information about the webkit-unassigned mailing list