Safari 10 has supported a new security feature "Content Security Policy Level 2", CSP2, that is a W3C standard proposed for mitigating common security attacks on the web applications, e.g. XSS.
CSP2 has an interesting directive "frame-ancestors" that replaces and obsolete existing X-Frame-Options header. If a document is delivered with frame-ancestors 'self' in the header a user-agent rejects loading of the document as a frame content of the other origins. And if "report-uri" is set together a user-agent sends a violation report to the provided endpoint to inform observation of framing attacks. This report could be a good information to be aware of HTTP/L7 client side attacks in the perfect world.
However, Safari had a flaw in the reporting mechanism that relative report endpoint URL is mistakenly resolved by the parent window’s origin.
Following diagram shows an example of framing attack that a malicious page in evil.csrf.jp tries to load a document of victim, alice.csrf.jp, in her iframe.
There sometimes be sensitive data in a document URL. For example, when you logged-in to Facebook and you opened a link to https://www.facebook.com/profile.php, Facebook redirects you to your profile page that URL contains your name in the path, e.g., https://www.facebook.com/muneaki.nishimura. Violation reports can contain such URLs as well. If victim’s URLs are stolen by abusing the flaw, the attacker can obviously know who visited attacker’s website.
The following URL is a proof of concept code of this issue. Vulnerable versions of Safari send a CSP report to evil.csrf.jp but fixed versions send to alice.csrf.jp. http://evil.csrf.jp/frame-ancestors.html
This issue has been officially disclosed as CVE-2016-7599 in their security advisories of iOS 10.2 but they didn't fixed it. Finally, this issue has been addressed on iOS 10.3 and Safari 10.1 on March 27, 2017.
Thanks for fixing the issue, Apple!