Menu
I'm implementing a "pass-through" for X-Frame-Options to let a partner site wrap my employer's site in an iframe, as per this article: http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
(splitting up URLS to post)
In a nutshell, our partner's page has an iframe with an URL against our domain. For any page in our domain, they'll add a special url argument like &@mykey=topleveldomain.com, telling us what the page's top level domain is.
Our filters pick up the partner TLD, if provided, from the URL, and validate it against a whitelist. If it's on the list, we ship the X-Frame-Options header with value ALLOW-FROM topleveldomain.com (and add a cookie for future clicks). If it's not on our whitelist, we ship SAMEORIGIN or DENY.
The problem is it looks like sending ALLOW-FROM domain results in a no-op overall for the latest Firefox and Google Chrome. IE8, at least, seems to be correctly implementing ALLOW-FROM.
Check out this page: http://www.enhanceie.com/test/clickjack. Right after the 5th (of 5) boxes that "should be showing content", is a box that should NOT be showing content, but which is. In this case, the page in the iframe is sending X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com, a decidedly different TLD than http://www.enhanceie.com. Yet, the frame still displays content.
Any insight as to whether X-Frame-Options is truly implemented with ALLOW-FROM across relevant (desktop) browsers? Perhaps the syntax has changed?
Some links of interest:
782
Chrome does not support the ALLOW-FROM directive in X-Frame-Options. So if we are going to do anything involving other domains, we need something similar. We can stitch together a patchwork configuration involving both headers, which does something more than just allow same-origin framing.
Chosen Solution As a possible workaround you can right-click the frame area with the error message and see if you can use "This Frame: Show Only This Frame" or "This Frame: Open Frame in New Tab" to get that page working.
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> , <iframe> , <embed> or <object> . Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.
X-Frame-Options Deprecated While the X-Frame-Options header is supported by the major browsers, it has been obsoleted in favour of the frame-ancestors directive from the CSP Level 2 specification.
ALLOW-FROM is not supported in Chrome or Safari. See MDN article: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
You are already doing the work to make a custom header and send it with the correct data, can you not just exclude the header when you detect it is from a valid partner and add DENY to every other request? I don't see the benefit of AllowFrom when you are already dynamically building the logic up?
61
I posted this question and never saw the feedback (which came in several months after, it seems :).
As Kinlan mentioned, ALLOW-FROM is not supported in all browsers as an X-Frame-Options value.
The solution was to branch based on browser type. For IE, ship X-Frame-Options. For everyone else, ship X-Content-Security-Policy.
Hope this helps, and sorry for taking so long to close the loop!
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
