<iframe> and <object> are both blank, but only in Firefox - html

I am attempting to embed one site into another site. I control both servers, which I will refer to here as "site1.com" (the site in the browser) and "site2.com" (the site I am trying to embed).
HTML embed code
Attempt 1, using iframe tag:
<iframe height="600" width="600" name="my other site"
src="https://site2.com/foo/bar">
Unable to display--your browser does not support frames.
</iframe>
Attempt 2, using object tag:
<object type="text/html" height="600" width="600" name="my other site"
data="https://site2.com/foo/bar"></object>
Things I know are not the problem
Secure/insecure mismatch
I've read that Firefox will not allow an HTTP embed into an HTTPS page. Both sites are HTTPS, so there is no mismatch. The loaded resources (CSS, etc) are also https, from same origin, so there is no mixed-content problem.
I have tried setting security.mixed_content.block_active_content to false, in case I was mistaken about this, but the iframe was still blank.
Invalid or untrusted certificates
Both sites are using valid certificates, signed by a proper trusted authority, and are not expired. In fact, we are using a subdomain wildcard certificate, so they are both using the same certificate (they both are in the same subdomain).
X-Frame-Options
The site that I am trying to embed has this response header:
X-Frame-Options: ALLOW-FROM SITE1.COM
Content-Security-Policy
The site that I am trying to embed has this response header (wrapped here for readability):
Content-Security-Policy:
frame-ancestors https://site1.com;
default-src 'self';
script-src https://site1.com 'self' 'unsafe-inline';
style-src https://site1.com 'self' 'unsafe-inline'
Extra disclosure, possibly not needed - these headers are being generated by a Django application server, using this config and the "django-csp" module.
X_FRAME_OPTIONS = 'Allow-From site1.com'
CSP_FRAME_ANCESTORS = ('https://site1.com',)
CSP_STYLE_SRC = ('https://site1.com', "'self'", "'unsafe-inline'")
CSP_SCRIPT_SRC = ('https://site1.com', "'self'", "'unsafe-inline'")
CORS
My understanding is that CORS is only in play when the request contains an "Origin" header. That doesn't seem to be happening here. I have also tried addressing CORS by using this header:
Access-Control-Allow-Origin: https://site1.com
But that appears to have no effect.
Ad blocker
I do not have an ad blocker in this Firefox install. I also removed all of my extensions and re-tested after a Firefox restart, the "blank iframe" behavior remains the same with no extensions installed at all.
Observed behavior
I have tested using the following browsers.
Google Chrome 58.0.3029.81 (64-bit) (macOS)
Safari 10.1 (macOS)
Firefox 53.0 (64-bit) (macOS)
Microsoft Edge 38.14393.0.0 (Windows 10)
Using Chrome, Safari, and Edge, the frame is shown like I expect - site2.com appears as a box inside of the site1.com page.
Using Firefox, I am shown an empty space of the size specified (600x600). If I used iframe, then there is a black border around it. If I used object, it's just a blank area with no border.
The most interesting thing is that if I open the developer console and reload the page, I see the requests to fetch site1.com and its CSS and so on, but there are no requests made for site2.com. It isn't that there is a problem showing site2.com, it is never requested at all.
Also, the developer console shows no errors or warnings about this. If there were an error condition or security exception preventing the loading of the second site, I would expect some sort of warning to be logged.
This has been driving me crazy for a few days. Any suggestions appreciated.

I reproduced the issue on my server which serves 2 domains, and then fixed it this way:
X-Frame-Options: ALLOW-FROM https://SITE1.COM
I added https://, as seen in MDN page for X-Frame-Options
You can observe the difference here (only with Firefox of course, as with other browsers both frames are shown): I pushed a php page that inserts the header without or with https://, and created this fiddle that insert 2 iframes: Firefox shows first iframe as empty, and second one with content (which echoes the value in header) on the right.
Since you are forced to put a "serialized origin" (protocol+FQDN), I wondered if you can put multiple entries, or wildcards. My understanding of RFC 7034 says you cannot.
Now about this detail:
The most interesting thing is that if I open the developer console and
reload the page, I see the requests to fetch site1.com and its CSS and
so on, but there are no requests made for site2.com. It isn't that
there is a problem showing site2.com, it is never requested at all.
That's because it was cached. I also saw that, but a force-refresh rightly showed a new request was made.

If you knew the source code (right click and view source of url to embed - but you control it in this case so you can copy and paste) and it was only a reasonably small amount of code (probable because you're using an iframe), then you could use the HTML5 srcdoc attribute to embed the html code, instead of pointing to the url. This would save a lot of hassle regarding unknown factors regarding the site you want to embed (CORS etc..) which you would not usually know if you didn't have control over the second site.
According to caniuse.com the srcdoc property has full support in Firefox since vsn 25 onwards (so since Sept 2013).
Hope this helps (Here's a tested jsfiddle example)

Related

Internet Explorer X-Frame-Options ALLOW-FROM not working in IE 11 and Edge

I am having an issue using X-Frame-Options to embed one site as an iFrame into another (different domains) with IE 11 and Edge. My research and experience indicate that IE doesn't yet support CSP Level 2 frame-ancestors, so I must use X-Frame-Options.
I have added the response header
X-Frame-Options: ALLOW-FROM https://<mysite>.com
to the site that needs to be embedded.
These are secured sites so I am unable to provide real URLs to this community.
When I launch the main site, which contains an iFrame with content from the second site, I am able to see the X-Frame-Options header in the response for the iframe content and it looks to be applied correctly. However, IE indicates "...modified this page to help prevent cross-site scripting" and my frame contains only the # symbol.
Due to timing and internal IT delays, I am unable to have both sites hosted in the same domain.
Can anyone help to explain what I did wrong in implementing X-Frame-Options or if there is another option to achieve the desired effect?
IE 11 not following standard, which means can not use "*", so have to give domain name with http/https.
def cors_set_access_control_headers
headers["Access-Control-Allow-Origin"] = "*"
headers["Access-Control-Allow-Methods"] = "GET"
headers["Access-Control-Request-Method"] = "*"
headers["Access-Control-Allow-Headers"] = "Origin, X-Requested-With, Content-Type, Accept, Authorization"
headers["X-Frame-Options"] = "ALLOW-FROM http://172.16.1.159"
headers["X-XSS-Protection"] = "0"
end
It turns out that the issue wasn't related to frames. The framed content had the same XSS error/note when accessed directly vs through an embedded iframe. The timing of the error showing threw me off since it was coincidental to the implementation of CSP level 2 frame-ancestors.
I have opened a case with MS to determine what in the content the XSS engine doesn't like and have had to disable the XSS in IE browsers with the X-XSS-Protection:0 response header.

Is my embedded Google Group blocked by FireFox because of an incorrect X-Frame-Options "Allow-From" value?

I'm trying to embed a Google Group into a web page on a site, but I cannot get it to work in all browsers and am stumped about why. Using the <iframe> and JavaScript code provided by the Google Groups configuration system, things work when I view the page in Safari (version 6.1, 8537.71) and Chrome (32.0.1700.107), but not FireFox (26.0) running on Mac OS X 10.8.5. Running FireFox's debug console reveals the following error:
Load denied by X-Frame-Options: https://groups.google.com/
does not permit framing by http://mysite.org/mypage
(where http://mysite.org/mypage is the actual page URL, of course). Now, the curious thing is that using the debug consoles in Chrome and Safari, they both report an error too—but it is about the X-Frame-Options header sent by Groups:
Invalid 'X-Frame-Options' header encountered when loading
'https://groups.google.com/forum/embed/?place=forum/myforum
&domain=mydomain.org&showtabs=false&parenturl=
http%3A%2F%2Fmydomain.org': 'ALLOW-FROM https://groups.google.com'
is not a recognized directive. The header will be ignored.
This seems to imply that the reason it works in Safari and Chrome is that Google is sending an invalid header (which seems unlikely) and Safari and Chrome therefore ignore it, or that both browsers are unable to interpret X-Frame-Options, which as far as I can tell, is not supposed to be the case.
Can anyone think of what might be going on, or suggest what other possible issues I can check for?
A past question on SO seemed to hit a similar or possibly the same problem, but the OP's problem apparently went away on its own, whereas mine persists whether I am logged in or out of my Google account.
EDIT 2014-02-06 #1
I've now determined that Chrome and Safari do not implement support for ALLOW-FROM in X-Frame-Options; that explains the messages in the consoles, and probably explains why those browsers do not block the embed Google Groups page. Also, if I interpret the definition of the ALLOW-FROM option correctly, the URI provided as the value should be the enclosing page; in other words, Google should be sending back ALLOW-FROM mydomain.org and not the value it is currently sending. I guess I must be doing something wrong, but I've followed exactly Google's instructions for setting up the iframe, including the part about supplying &domain=yourdomain.com.
EDIT 2014-02-06 #2
In view of the above, my original question is basically answered: the reason Safari and Chrome display the embedded page is that they currently ignore the security header value, whereas FireFox doesn't, and correctly blocks the embedding because the value of ALLOW-FROM is not the domain of the page enclosing the iframe (mydomain.org) as it needs to be.
So the question is now, why does Google set ALLOW-FROM to https://groups.google.com rather than mydomain.org.
EDIT 2014-02-06 #3
Solved. The reason that Google was sending the X-Frame-Options value is that my <iframe> code was incorrect. For reasons that I can no longer reconstruct at this time, I was led to believe that ampersands in the src attribute value needed to be escaped, like this:
<html><body>
<iframe id="forum_embed" src="javascript:void(0)"
scrolling="no" frameborder="0" width="746" height="1200">
</iframe>
<script type="text/javascript">
document.getElementById('forum_embed').src =
"https://groups.google.com/forum/embed/?place=forum/sbml-discuss"
+ "&parenturl=" + encodeURIComponent(window.location.href);
</script>
</body></html>
In fact, it does not work if written that way. But the following does:
<html><body>
<iframe id="forum_embed" src="javascript:void(0)"
scrolling="no" frameborder="0" width="746" height="1200">
</iframe>
<script type="text/javascript">
document.getElementById('forum_embed').src =
"https://groups.google.com/forum/embed/?place=forum/sbml-discuss"
+ "&parenturl=" + encodeURIComponent(window.location.href);
</script>
</body></html>
(The difference is in &parenturl.) And this is exactly what Google's instructions say to do. Which is, you know, really embarrasing....
This is controlled by the parentUrl url-param to the iframe src attribute.
It might just be the chrome console encoding it, but it looks like the URL for the iframe src has the '&' characters encoded.
Are you hardcoding the parentUrl attribute? or are you using 'encodeURIComponent(window.location.href)'
(from the help docs: https://support.google.com/groups/answer/1191206?hl=en)

iframe contents cant appear in Firefox

Below is my code:
<div style="border: solid 1px #000000; margin: 5px;">
<iframe src="http://www.w3schools.com" width="100%" height="300px" scrolling="yes"><p>Your browser does not support iframe.</p></iframe>
</div>
Contents of iframe works well in chrome but not in firefox. I've disabled add-ons but my iframe is still empty. Can anyone please help me?
If you are trying to add this Iframe on a SSL-encrypted website (https://), it won't work any more since Firefox 23 because Mozilla has decided to blocked all unencrypted content on encrypted websites (for example http-iframes on https-websites).
You can change this behaviour in your own Firefox installation by typing about:config in the address bar and setting security.mixed_content.block_active_content to false.
But that won't help you for all other FF23-visitors on your website.
As of 05/2018, the iframe lead is denied by browser due to X-Frame-Options header set to 'sameorigin'.
Tested the page with Firefox and getting blank iframe.
Here is what console says:
Load denied by X-Frame-Options: https://www.w3schools.com/ does not permit cross-origin framing.
Why that?I'll give Chrome console a chance, here's what it says:
Refused to display 'https://www.w3schools.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Basically, X-Frame-Options header (do not confuse that with CORS), is set to 'sameorigin', that means that the browser is allowed to display the iframe content only if embedded in same domain and same protocol (https://www.w3schools.com/ is not sameorigin of http://www.w3schools.com/).
Here are some docs aboiut x-frame-options:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
I don't know if its related but when I try to request w3schools by c# it responses 503 forbidden error. So they may use something to prevent showing up on iframes, etc. Facebook has similiar restrictions, you cannot display their likebox iframe unless you log in.
Why no one has mentioned CORS yet?
FROM mdn
Cross-Origin Resource Sharing (CORS) is a mechanism that uses
additional HTTP headers to let a user agent gain permission to access
selected resources from a server on a different origin (domain) than
the site currently in use. A user agent makes a cross-origin HTTP
request when it requests a resource from a different domain, protocol,
or port than the one from which the current document originated.
An example of a cross-origin request: A HTML page served from
http://domain-a.com makes an src request for
http://domain-b.com/image.jpg. Many pages on the web today load
resources like CSS stylesheets, images, and scripts from separate
domains, such as content delivery networks (CDNs).
For security reasons, browsers restrict cross-origin HTTP requests
initiated from within scripts. For example, XMLHttpRequest and the
Fetch API follow the same-origin policy. This means that a web
application using those APIs can only request HTTP resources from the
same domain the application was loaded from unless CORS headers are
used.
This means that the websites you are trying to enter from the iframe are set to deny requests from your site or others (if not all).
I had the same issue. For me the cause was a trailing slash at the end of the url.
Doesn't work:
<iframe src="http://example.com/some/sub/folder/"></iframe>
Works:
<iframe src="http://example.com/some/sub/folder"></iframe>
You need to have source file of iframe on localhost.
Firefox and Chrome doesn't display this iframe:
<iframe src="https://www.yourdomain.com/form.html"></iframe>
Works:
<iframe src="/form.html"></iframe>

Invalid 'X-Frame-Options' header from google's Doubleclick response

We use doubleclick from Google to track user information with a floodlight tag in an IFrame, but recently the response is causing an error in the Chrome dev tools:
Invalid 'X-Frame-Options' header encountered when loading 'http://123.fls.doubleclick.net/activityi;src=123;type=123;cat=123;ord=123': 'ALLOWALL' is not a recognized directive. The header will be ignored.
Here is a blog post on the matter: http://ipsec.pl/node/1094
It looks like ALLOWALL has recently been added to allow any site to use the code as a src (similar to not including that option at all) and doubleclick is including this option in their response. Out of IE, Firefox and Chrome, Chrome is the only browser that throws the error. Does that mean that Google is using an option in doubleclick that doesn't work in their own browser? It's hard to imagine a Google team not testing in Chrome.
It seems to me that if the header is being ignored, and the header has the same effect as not including any cross site restrictions with X-Frame-Options, the error will not affect anything. Also, since the error occurs on the response, the tracking that is done with the original request should be fine, right?
The issue was filed as a bug report: Bug 110857 - X-Frame-Options should accept ALLOWALL as a valid value and
has been addressed and the fix is in the main branch of WebKit, once the latest WebKit engine is in use by Chrome, the messages will disappear.
for more information see: Webkit Changeset 144105

Chrome not honoring protocol-relative URL references?

I have noticed today for the first time that Chrome (and only Chrome) does not pay attention to protocol-relative URL references. For example:
<img src='//www.example.net/image.png />
should source as https when it appears on https pages, and should source as http when it appears on http pages. IE and FF are still working this way, but Chrome is now sourcing it only as
//www.example.net/image.png
so when it appears on an https page, the page becomes unsecure. Anyone else notice this recently?
Chrome does respect protocol relative URL's, looking at your example it is malformed (there is no closing ' on your path.