Kind of a 101 question about X-Frame-Options and/or Content-Security-Policy: frame-ancestors: if one intends to develop an application using iframed production sites (on which I can adjust headers) on a local machine, would they have to add localhost to frame-ancestors in the Content-Security-Policy? Will X-Frame-Options SAMEORIGIN not work at all?
You would want to strip those headers from the framed response so they don't prevent rendering.
Locally, the only thing that applies would be frame-src coming in the localhost response allowing you to embed your production sites (not setting csp at all would also work).
Related
I need to have https://web.whatsapp.com embedded in my website via iframe. I get the error of X-Frame-Options. I use express server and I tried to configure it with helmet:
app.use(
helmet.frameguard({
action: "sameorigin",
})
)
Doesn't seem to work. Same with deny. I read that ALLOW-FROM is not supported in Chrome browser anymore. Is there any chance to bypass or allow X-Frame-Options to accept certain origins? (Maybe there is any other options how to embed https://web.whatsapp.com to my website?).
X-Frame-Options prevents a site from being framed. As web.whatsapp.com prevents framing, there is nothing you can do to allow it being framed, unless you proxy the connection and remove headers. Adding headers to the site framing the other won't change anything.
So I'm trying to avoid using (another) page rule to disable Rocketloader for one of my subdomains, since we can't use a RegEx to select multiple specific subdomains under a single page rule, and only get 3 page rules for free accounts.
According to this page:
https://support.cloudflare.com/hc/en-us/articles/216537517-Using-Content-Security-Policy-CSP-with-Cloudflare
I can just add a header to the domain to allow scripts from CloudFlare:
add_header Content-Security-Policy "script-src 'self' ajax.cloudflare.com;";
I did so in the Nginx config for that subdomain (it's a Chronograph container actually), restarted Nginx, tested to make sure it "took", which it did:
But then when I try to load the domain, it won't load, and the inspector shows this:
Not being super familiar with this, does anyone know where I screwed it up?
where I screwed it up?
First of all, here:
I can just add a header to the domain to allow scripts from CloudFlare:
add_header Content-Security-Policy "script-src 'self' ajax.cloudflare.com;";
I did so in the Nginx config
And secondly, you trusted the report-uri service, but it failed you.
You have had an issue with ajax.cloudflare.com BEFORE adding CSP header into Nginx config (otherwise, why add it). This means that you already have a CSP published via an HTTP header or a meta tag <meta http-equiv= 'Content-Security-Policy'>.
By adding the CSP header to the Nginx configuration, you have added a second policy to the pages.
Multiple CSPs work as sequential filters - all sources must pass through both CSPs to be resolved. The second CSP allows ajax.cloudflare.com host-source, but the first one still prohibits it (that you are observe in the inspector).
You have to figure out where the first CSP is published and to add ajax.cloudflare.com into it, instead of publish second CSP.
No one know what is under the hood of the report-uri and how it will react if two CSP HTTP headers or an HTTP header paired with a meta tag are published simultaneously
Have a look which CSP and how many of them the browser actually gets, the guide is here.
In case of 2 CSP headers you will see something like that:
In case of CSP meta tag you can easily check the by inspecting the HTML code.
I think the report-uri just did not expect such a situation.
why google.com not set includeSubDomains directive on http strict transport security response header ?
google.com HSTS resonse header is something like:
Strict-Transport-Security:max-age=86400
Why not
Strict-Transport-Security: max-age=86400; includeSubDomains
The second one should be more secure from my side, is that right ??
It is static
Using Google Chrome, you can go to chrome://net-internals/#hsts and Query different domains. Entering google.com and clicking on Query will bring back a list of results.
In that result list, you can see that static_sts_include_subdomains is true and dynamic_sts_include_subdomains is false. This is better than setting it dynamically, which is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication. In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source.
Hope this helps
Yes it is more secure to use includeSubDomains.
For example an attacker could set up and use a subdomain (e.g. hacked.google.com) and access that over HTTP and and use that to access or override cookies set at top level domain (google.com) even though that top level domain is secured with HSTS. Of course if you're using Secure attribute on your cookies then this might not be an issue but this is just one example of why to use includeSubDomains.
You cannot set the includeSubDomains attrribute unless all subdomains are available on HTTPS (obviously). So if Google had blog.google.com and had still not upgraded this to HTTPS then that might explain why they would not use includeSubDomains at the top level domain.
However, as #Horkine rightly points out, Google preloads their domains into the Chrome browser code (and that preload list is also picked up by other browsers) so this HTTP header isn't used for modern browsers.
Weirldy there are some inconsitencies between the preloaded version and the HTTP HTTP Headers version. That is very odd to be honest. Incidentally these discrepancies also breaks their own rules for preloading.
www.google.com
The preloaded version for www.google.com does have the includeSubDomains attribute.
The Strict-Transport-Security HTTP Header version does not have the includeSubDomains attribute but not the preload attribute.
google.com
The preloaded version for google.com does have the includeSubDomains attribute
No Strict-Transport-Security HTTP header is published.
Why these inconsistencies? We can only guess:
It could be that they never got round to updating their HTTP Header after finishing the upgrade to all their sites?
Or it could be because some of the apps do browser detection for older browsers (which do not include the preload code, but does understand the HSTS header) and redirects older browsers to http://old.google.com for some reason?
Or it could be region specific?
All of it is a guess really, as only Google can answer and I'm not aware of any documentation of what they use on their own site or why.
But, yes, to answer you last question it is more secure to include includeSubDomains (if possible) and it is even more secure to preload (though not without risks unless you are 100% confident you are only using HTTPS).
I have a web page that renders some nested iFrames. Lets say abc.com loads def.com, that in-turn opens ghi.com in another iFrame. abc.com -> def.com -> ghi.com
ghi.com has option set to only allow some specific sites to iFrame it. What should be the setting in ghi.com to allow it to be rendered? Do we need to white list both abc.com and def.com, or only def.com, or abc.com?
I ran into this situation with X-Frame-Options when trying to allow this scenario in IE 11. I found that putting an X-Frame-Options value of "ALLOW-FROM top-level-site-domain" worked for the response in both of the nested iFrames. Using your example, both def.com and ghi.com response would set headers similar to:
"X-Frame-Options": ALLOW-FROM abc.com
As a side note, according to OWasp, setting the X-Frame-Options header to ALLOW-FROM for def.com and SAMEORIGIN for ghi.com in your example will not work.
Remember that other browsers such as Chrome support Content-Security-Policy which you'll also want to set. In our case our domains were all subdomains so our scenario worked out easily with this header using wildcards. A scenario of first.example.com -> second.example.com -> third.example.com allowed us to set the following for second and third.example.com response header:
"Content-Security-Policy": frame-ancestors 'self' https://*.example.com
I am adding the HTTP Strict Transport Security header to a website.
Does it prevent loading of resources over HTTP that are not in same domain?
HSTS only applies to the domain it's sent with, and any subdomains if the includeSubDomains attribute is also set.
Any other domains are unaffected.
However one thing to be careful of is if your main domain (www.example.com) uses the same config as the bare domain (example.com), which is quite common, and you issue the HSTS header on both (perhaps without realising it's also on the bare domain) and use the includeSubDomains header. If that's the case then you can easily block access to other domains you did not intend to, which are still on http (e.g. http://blog.example.com or http://internal.example.com) if someone visits the bare domain.
BTW if you were wanting to upgrade all the http requests to https you could use Content Security Policy (CSP) which has an upgrade-insecure-requests option. However browser support of that is not yet universal. You can also use CSP to help you identify mixed content as discussed here.