877724 - X-Frame-Options origin checks should check entire frame tree (like IE 9)

Status: RESOLVED DUPLICATE of bug 725490

(Core :: DOM: Core & HTML, defect)

Description

[John]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36

Steps to reproduce:

I tried to run from an original domain an iframe that runs from sand-boxes. It worked. (The original domain has iframe Same-Origin protection). Here is a proof of a vulnerability i found in Google:
Proof that the iframe is executed from an iframe:
http://gyazo.com/99b706b4991920a21d2cd89b7fb633d0.png
As you can see, the iframe is executed from producer.googleusercontent.com.
However, i can still iframe google from it even though it is not part of google.com's domain so it should not be consider as Same-Origin. 
POC:
http://gyazo.com/5f2c61843ff0419f83b6f13eaa4e1840.png
http://gyazo.com/b0924537ab268fd4766fdb25c6233aa9.png

(To enter google.com/producer with firefox, please change you need to change your user-agent to Chrome).


More Information:
X-Frame-Options http header was made to protect websites from javascript-redirection and clickjacking vulnerabilities in an iframe. The X-Frame-Options has two main inputs: Deny or SAMEORIGIN. Firefox, and other browsers have a wrong behavior when they check if the iframe is on same-origin (In fact, this issue was fixed only in IE as far as i know). Basically, what happens is that they check the window.top and they are not checking the window.parent. This makes many website vulnerable.

For more information about the issue:http://www.skeletonscribe.net/2012/06/x-frame-options-sameorigin-warning.html

Regards,
Johnathan


Actual results:

It executed.


Expected results:

It should've hide it.

Comment 1

[John]

Proof that google.com uses x-frame-options of same-origin: http://gyazo.com/cfa3488137a3105fbb7e0791001c9c63.png

Comment 2

[Daniel Veditz [:dveditz]]

According to http://webstersprodigy.net/2012/09/13/clickjacking-google/ (thanks for the link, Johnathan) IE 9 changed its behavior and now blocks up the entire chain. Testing in IE10 seemed to bear this out. It's unfortunate that the X-F-O draft, which was supposed to represent the browser status quo and is co-authored by a Microsoft employee, was not updated when IE changed its implementation.

Since blocking frames all the way up (for both SAMEORIGIN and ALLOW-FROM) was our preference in the first place (see CSP frame-ancestors) we should do this too. It's safer and the ONLY reason we were doing the less-safe behavior (IE compatibility) is now moot.

Comment 3

[Daniel Veditz [:dveditz]]

aha, found it... and look at that, even has a patch