Bug 215356 – same-site navigation within iframes is still referrerpolicy=origin when "Prevent cross-site tracking" enabled

• Component: Frames
• Status: NEW

[Daniel Roesler]

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.

[Radar WebKit Bug Importer]

<rdar://problem/66849267>

I am also having this same issue. All of a sudden my iframe is not picking up the cookies within an iframe of the same domain that was set outside of it.

[Charlie Wolfe]

I can't reproduce this on the latest WebKit builds.

[Daniel Roesler]

(In reply to Charlie Wolfe from comment #3)
> I can't reproduce this on the latest WebKit builds.

Can you please try again? I fixed the proof of concept demo:  https://daylightpirates.org/iframe-referrerpolicy-test

[Charlie Wolfe]

Pull request: https://github.com/WebKit/WebKit/pull/3788

Is this confirmed a bug and being fixed?

[Charlie Wolfe]

(In reply to cblaze22 from comment #6)
> Is this confirmed a bug and being fixed?

I believe this may be a bug, but the bug being reported is only related to the Referer header being stripped in cases when it shouldn't be. The fix I am proposing won't resolve any issues you are having regarding cookies (which you initially mentioned).

If you think you are experiencing another issue. Please file a separate bug.

[Dasa Paddock]

I see that PR https://github.com/WebKit/WebKit/pull/3788 was closed. Is this no longer considered a bug?