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.
Related
I'm developing a ionic app and I need to make some CORS requests for dev purpose.
I use chrome v49 with -disable-web-security. I also use an .htcacces to allow OPTIONS request.
But i still get an error 405.
Chrome header sum'up
Try adding the chrome Extension Allow-Control-Allow-Origin: * from chrome webstore , enable
cross-origin resource sharing
from its option, then reload the page
Thanks for your answer. We already tried that but it did not succeed either.
The problem was server side. We used symphony witch refuse everything with is rly strict policy. To solve this we used NelmioCorsBundle.
I have my personal Google Chrome extension that adds an iframe to every page.
Now, it worked perfectly until a couple of days earlier.
Now it wont work on https pages!
The iframe source is HTTP.
The console is reporting:
[blocked] The page at https://example.com ran insecure content from http://mysite.com
Now, I know about mixed content issue, but it worked perfectly before. Why isnt it working now and how to fix it?
Anyone?
Thanks
Well, a new chrome update was released a couple of days ago. Check the patch notes from that release if they changed anything security related to make Chrome extensions require both HTTP or both HTTPS, not mixed.
When I try to launch a custom protocol from https connection, Chrome version 30 is giving the following error.
[blocked] The page at https://something.com ran insecure content from custom-protocol://somethingelse.com/myapp
Chrome version 29 works fine.
Did anyone come across similar issue?
Is this a new issue/feature in chrome?
Appreciate any response.
Thanks in advance.
I did, and the problem was that I was using https to access the page, the link was in an iframe and most of all, the certificate used in the https was not trusted. After moving to https works fine.
And by the way, it was working in FireFox.
Hope it helps!
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
We developed new file action for our web-app, it works fine when using chrome or Firefox but on IE we have problems, when trying to understand the issues we noticed that when the message goes to our web-app it doesn't send any cookies including the session cookie although the web-app sends set-cookie header.
why is it happens?
OK, we found the problem, apparently when using iframes in IE cookies are blocked as IE refers to Iframes as third party app, to unblock cookies we should to add privacy policy to the headers using P3P header.
good place to read about is - Cookie blocked/not saved in IFRAME in Internet Explorer.
This sounds like a possible bug on our end. Can you email us at API AT box.com with specific information about the request that's being sent as well as which version of IE you're using?