I noticed after updating to Google Chrome (21.0.1180.89) I’m getting allot of errors in the developer tab; especially if I visit my own phpMyAdmin site.
There are all the same and are some sort of security against Cross-Site Scripting; are there anything I can do to resolve?
Unrecognized Content-Security-Policy directive 'allow'.
Unrecognized Content-Security-Policy directive 'options'.
The allow and options directives are both part of Mozilla's original definition of Content Security Policy. Chrome implements the current W3C standard, which has made several changes from Mozilla's original proposal.
allow has been replaced with default-src, and sets a default source list for the other CSP directives.
options has been replaced with 'unsafe-inline' and 'unsafe-eval' (with the single-quotes) sources on either the script-src or style-src directives.
Both of those old-style directive still work in Firefox, using the X-Content-Security-Policy header. If a website delivers a WebKit-prefixed header (X-WebKit-CSP), it should use the current standard.
Note that WebKit has implemented the unprefixed header (Content-Security-Policy) in trunk, and it should be rolling out to stable WebKit-based browsers over the next few months. If you're not already setting the canonical header, now is a good time to start thinking about it. :)
Got a similar error on Chrome v 48.0.2564.116 m
"Unrecognized Content-Security-Policy directive 'frame-ancestors'."
But working absolutely fine on IE 11, FF and safari.
This is just an warning message on chrome and there is no impact on the functionality of the site.
Related
When using Google Analytics, I'm getting the following error from Safari 13.1 but not from Chrome:
Refused to connect to https://www.google-analytics.com/j/collect?XYZ
because it does not appear in the connect-src directive of the Content Security Policy.
My application doesn't try to connect to www.google-analytics.com, but it downloads a script from www.googletagmanager.com which in turn downloads a script from www.google-analytics.com.
My CSP are configured as follows:
script-src 'self' 'unsafe-eval' data: www.google-analytics.com www.googletagmanager.com www.google.com www.gstatic.com
connect-src 'self'
So as Safari says, I don't have google-analytics in connect-src, but that doesn't seem to be a problem for Chrome.
Is my CSP wrong (and Chrome is being too permissive) or is this a bug in Safari?
Safari is right. Chrome is being too permissive:
The HTTP Content-Security-Policy (CSP) script-src directive specifies valid sources for JavaScript.
Note that this statement is not qualified.
Chrome also violates other postulates of CSP. For example, blocked-uri for different origins requires that the URI path is stripped, but Chrome doesn't do that and Safari does.
At this point in time Safari seems to be more compliant/strict than Chrome, but in any case you should go by the stricter browser because, well, you don't really have a choice...
I am implementing an OpenID Connect client web application. After the user is successfully authenticated in the identity provider, they are redirected back over to my web application. Once they arrive, depending on the value of some query parameters they are redirected to a URL. When the redirection occurs Chrome throws this error in the console:
Refused to send form data to 'https://my-domain-a.com/' because it violates the following Content Security Policy directive: "form-action 'self' https://my-domain-b.com/receive-token".
After some googling I tried adding a Content-Security-Policy header as:
content-security-policy: form-action 'self' https://my-domain-a.com
This does not seem to have any affect and I still receive this message.
I have 2 questions:
How do I fix this?
Why is Chrome throwing this error off of a 301 redirect?
After much googling (and profanity) I figured out why this is happening, as well as an (ugly) fix.
During my experiments, I noticed that all Chromium browser descendants (Chromium, Chrome, and Vivaldi) had this issue. Non-Chromium browser descendants (Firefox and Safari) did not. As it turns out, the identity provider was setting a content security policy directive of: form-action 'self' https://my-domain-b.com/receive-token. Since my browser was getting redirected from the identity provider to my-domain-b.com to my-domain-a.com the Chromium descendants flagged the redirect from my-domain-b.com to my-domain-a.com as violating the content security policy set by the identity provider. I unfortunately don't know the spec well enough to say which of the 2 behaviors exhibited by the different browsers is the most correct...
I fixed this issue by doing a somewhat ugly hack. Rather than doing a 301 redirect from my-domain-b.com to my-domain-a.com, I instead had my-domain-b.com render a simple HTML page that immediately submitted to my-domain-a.com:
<html><body onload="window.location='https://my-domain-a.com?my_param=my_value'"/></html>
This solution satisfied the Chromium descendants since there was no longer a redirect to an unrecognized domain. In my case relying on Javascript is acceptable as the site the user is redirected to is an Angular app, so the user must have Javascript enabled.
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.
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