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
Related
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)
We recently discovered an interesting bug in newly released Chrome v.39.
It just crashed with standard "Aw Snap!" message on every page with an iframe if that iframe loads a page with Content-Security-Policy HTTP header. This blocked out web-site because we host some third-party ads.
From what i found the "Content-Security-Policy" header is a W3C standard and Google Chrome used to support in between v.25 and v.38 releases. But from now they don't.
Does anyone know a nice practical solution for this issue? Is there a way to prevent Chrome from crashing without this workaround?
If you want support Chrome 39/40, I found that adding the protocol in front of domain would prevent the crash (It's not required in CSP 2.0, but it's better than crash).
If you want support Chrome 41, it didn't crash even without protocol name.
Hope this helps.
In order to fix the issue we had to add a logic that sends X-Content-Security-Policy to all but IE and Content-Security-Policy to IE only. This is ugly code/solution but at least it stopped crashing.
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)
This example to load a url in an iframe works. However when I change url to something like http://www.yahoo.com the iframe doesn't load antyhing
Here is an example side by side.
In Network tab of developer tools for Chrome, I see that request to Yahoo was cancelled. In FF it doesn't give any errors, just doesn't return any content. IE9 gives a message that It cannot display this content.
This happens in Chrome, FF and IE9 (I haven't tested previous versions of IE).
That is because Yahoo itself prevents this from happening.
It has been noted here: https://stackoverflow.com/a/9013722/476786
To see for yourself, try setting the source to http://www.google.com/ which won't work as well, but then try http://www.bbc.co.uk/ and that will work.
Possibly works as described here: https://stackoverflow.com/a/2896705/476786 using X-FRAME-OPTIONS
If the site hosting the webpage forces the use of a secure HTTPS connection, some browsers (chrome for sure) will require that all network resources use HTTPS as well.
Basically if your site forces HTTPS, try setting src="https://yahoo.com"
This won't solve OP's answer directly due to it being a limitation of Yahoo itself, but other people viewing this page might be experiencing this issue as a result of this (I was).
Google Chrome 17 introduced a new feature which preloads a webpage to improve rendering speed upon actually making the request (hitting enter in the omnibar).
Two questions:
Is there a HTTP header to detect such a request on server side, and if one actually exists what is the proper response in order to prevent such preloading (to prevent unintended requests which might have unwanted effects)?
Does Google Chrome check the robots.txt before making preload requests?
Is there a robots.txt setting which targets only this specific behaviour? (I supose/hope disallow already works).
Is there a meta tag to inform Google Chrome to never preload again on the current domain?
When Firefox pre-fetches content (at the behest of the referrer page’s
markup), it sends the following header with the request: X-moz:
prefetch
Safari does similarly, using: X-Purpose: preview. According to this
ticket , Chrome does, too.
For pre-rendering, Chrome does not send any header whatsoever to the
client. Instead, one must use the Page Visibility API, in JS
source, additional reading
Chrome stopped sending X-Purpose header in 2011 and they stated that they won't fix it there: https://code.google.com/p/chromium/issues/detail?id=86175.
They re-introduced sending Purpose:prefetch headers with all nostate-prefetch requests back in 2018 as stated by the last comment on this issue. https://bugs.chromium.org/p/chromium/issues/detail?id=86175#c65