84

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:

Community
  • 1
  • 1
Rob
  • 1,351
  • 1
  • 11
  • 11
  • 1
    If you figure anything more out on your own then feel free to post your own answer. You'll get an upvote from me! – Prestaul Jun 05 '12 at 15:28
  • A patch was added for Firefox yesterday: https://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... – Prestaul Aug 24 '12 at 13:07
  • 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. – Mark Jan 20 '16 at 18:37

3 Answers3

45

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?

groovecoder
  • 1,551
  • 1
  • 17
  • 27
Kinlan
  • 16,315
  • 5
  • 56
  • 88
  • 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. – rbrc Feb 15 '13 at 15:43
  • Yeah I know, which is why I suggested to do it the opposite way around. – Kinlan Feb 26 '13 at 20:08
  • 4
    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. – rbrc Feb 27 '13 at 01:12
  • 3
    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. – Rob Oct 04 '13 at 20:32
  • The URL parameter, coming from the client, is also an unreliable mechanism because it is coming from the client. – Sven Nov 25 '16 at 14:31
25

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!

Michael
  • 8,362
  • 6
  • 61
  • 88
Rob
  • 1,351
  • 1
  • 11
  • 11
  • 7
    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. – JT. Mar 18 '14 at 03:53
  • 6
    2018 update: [`Content-Security-Policy` is now well-supported](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#Browser_compatibility). – rinogo Nov 20 '18 at 18:23
12

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.

Stefan Steiger
  • 78,642
  • 66
  • 377
  • 442
  • 9
    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: https://martijnvanlambalgen.wordpress.com/2015/06/28/clickjacking/ – Myrddin81 Sep 15 '17 at 06:33