Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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

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 5, 2012 at 15:28 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... – Prestaul Aug 24, 2012 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, 2016 at 18:37

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?

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, 2013 at 15:43 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, 2013 at 1:12 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 4, 2013 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, 2016 at 14:31

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!

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, 2014 at 3:53

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.
                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
– Myrddin81
                Sep 15, 2017 at 6:33
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.