X-Frame-Options: ALLOW-FROM in firefox and chrome

Question

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:

• Draft rfc on x-frame-options: https://datatracker.ietf.org/doc/html/draft-gondrom-frame-options-01
• developer.mozilla article discussing the header as a 2-option header (sameorigin or deny). https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
• msdn blog that initiated the whole thing: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
• msdn blog that talks about 3 values: adding allow-from origin http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

Internment

If you figure anything more out on your own then feel free to post your own answer. You'll get an upvote from me! – Hepza

A patch was added for Firefox yesterday: bugzilla.mozilla.org/show_bug.cgi?id=690168 We'll see if it makes it through review and out to a browser near you soon... – Hepza

Old quesiton, but for posterity -- the method you described (passing the TLD as an argument to the iframe) would be very easily defeated by anyone who wants to embed your content. They'd just view source, see what you're doing, and copy/paste. Since ALLOW-FROM is not yet reliable, you could use a shared secret that gets cryptographically hashed with the current time (within a window) and included in the iframe URL. On the iframe side, verify the hashed shared secret. Content thieves could steal that hash but it would only work for a brief window, effectively blocking unauthorized embeds. – Shuman

Answer 1

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?

Whalen

He's implementing the 4 step security under the Tokens heading on the linked msdn page, which won't work in chrome and safari unfortunately. – Shamekashameless

Yeah I know, which is why I suggested to do it the opposite way around. – Whalen

He'd be looking at the referer header then, which is a decent way of doing it although referer spoofing is alive and well. It is significantly harder to do if all the pages in question are HTTPS. AllowFrom would definitely be preferable. – Shamekashameless

Sorry, edits cut off my explanation! We decided HTTP_REFERER, coming from the client, was an unreliable mechanism to use for gating the decision. Also, we found some browsers (I belive IE in particular) do not pass down HTTP_REFERER from the top-level iframe-containing page. So we had no reliable way to tell who was framing us from the server. – Internment

The URL parameter, coming from the client, is also an unreliable mechanism because it is coming from the client. – Diatomite

Answer 2

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!

Internment

In its current form, X-Content-Security-Policy does not provide a cross-browser analog for ALLOW-FROM. Firefox supports frame-ancestors, and an upcoming spec supports frame-options. At the moment, Chrome only supports these frame-ancestors behind a runtime flag. frame-src is available, but this is the parent frame controlling child frames, rather than the child frame specifying its allowed parents. – Hasidism

2018 update: Content-Security-Policy is now well-supported. – Biannulate

Answer 3

For Chrome, instead of

response.AppendHeader("X-Frame-Options", "ALLOW-FROM " + host);

you need to add Content-Security-Policy

string selfAuth = System.Web.HttpContext.Current.Request.Url.Authority;
string refAuth = System.Web.HttpContext.Current.Request.UrlReferrer.Authority;
response.AppendHeader("Content-Security-Policy", "default-src 'self' 'unsafe-inline' 'unsafe-eval' data: *.msecnd.net vortex.data.microsoft.com " + selfAuth + " " + refAuth);

to the HTTP-response-headers.
Note that this assumes you checked on the server whether or not refAuth is allowed.
And also, note that you need to do browser-detection in order to avoid adding the allow-from header for Chrome (outputs error on console).

For details, see my answer here.

Tensible

If you want to avoid clickjacking, Content-Security-Policy can be used, but definitely not by adding the 'default-src' attribute, because that has completely different effects. You'll want to use the 'frame-ancestors'. That is similar to the X-Frame-Options, and it's a bit more flexible in that it allows you to specify multiple domains. See: martijnvanlambalgen.wordpress.com/2015/06/28/clickjacking – Bismuthic