Hello I am trying to display a part of an website in an iFrame. For example: IP 1.1.1.1 wants to iframe 1.1.1.2.
In apache2 security.conf it is set to:
Header set X-Frame-Options: "sameorigin"
I tried a lot of different forms of ALLOW FROM but nothing worked. I guess those solutions are outdated.
header module from apache 2 is enabled.
Is there any workaround on that? It is really a simple displaying which costs way too much time :D
Tyvm for any hints!
ALLOWFROM is not supported in most browsers. Instead you should set Content-Security-Policy with "frame-ancestors 'self' ", where would be the other host or ip that should be able to frame. You could add multiple sources if you like, not like X-Frame-Options which is limited to one source.
Related
How do you do this? I want only one other website to be able to load my main website in an iFrame but nothing is working.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors
Apparently as I understand it the protocol you set in .htaccess is this
So far I've tried:
1.
Header set Content-Security-Policy "frame-ancestors 'self' https://example.subdomain.co;"
2.
Header always set Content-Security-Policy "frame-ancestors 'self' 'https://example.subdomain.co';"
3.
Header set Content-Security-Policy "frame-ancestors 'self' 'https://example.subdomain.co';"
None of these work. When I try to load an iframe of example.com inside https://example.subdomain.co I get the following error:
Refused to display 'https://example.com/' in a frame because it set
'X-Frame-Options' to 'sameorigin'.
And then I get more confused because apparently you can only do DENY and SAMEORIGIN with this.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
The X-Frame-Options HTTP response header can be used to indicate
whether or not a browser should be allowed to render a page in a
<frame>, <iframe>, <embed> or <object>. Sites can use this to avoid
click-jacking attacks, by ensuring that their content is not embedded into other sites.
The added security is provided only if the user accessing the document
is using a browser that supports X-Frame-Options.
The one I would have wanted is ALLOW FROM but
ALLOW-FROM uri This is an obsolete directive that no longer works in
modern browsers. Don't use it. In supporting legacy browsers, a page
can be displayed in a frame only on the specified origin uri. Note
that in the legacy Firefox implementation this still suffered from the
same problem as SAMEORIGIN did — it doesn't check the frame ancestors
to see if they are in the same origin. The Content-Security-Policy
HTTP header has a frame-ancestors directive which you can use instead.
It's deprecated and it doesn't work.
Refused to display in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'
This answer doesn't help because they don't talk about what I want to do, they just explain what it is.
How to set 'X-Frame-Options' on iframe?
Again, not helpful because it's explaining to OP that the header is set on the website in the iframe source.
Is there a way to set it X-Frame-Options for frame-ancestors somehow to make this work so that I can load an iframe of my website on one other specific website? Or is this not possible?
When you set frame-ancestors correctly all browsers that understand it will disregard X-Frame-Options. This means that you can set both headers and use ALLOW-FROM as you will then server X-Frame-Options to IE and frame-ancestors to other browsers.
Have you checked if your Content-Security-Policy is present as a response header? Your first version is the most correct one, but you can drop the scheme as such: "frame-ancestors 'self' example.subdomain.co;", there should not be any single quotes around hosts in sources.
I am sorting out a website that will be getting pen-tested soon, we've have been asked to add the X-Frame-Options header to our server configuration. When adding the following header it gives me an error message in the console.log where we are using iframes
-- nginx header --
add_header 'X-Frame-Options' "SAMEORIGIN";
-- Error --
`Refused to display 'https://api.domain.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Obviously I understand the security reasons for this header but our website has an iframe that we simply cannot change & it is on a different domain e.g oldapp.domain.com rather than api.domain.com.
I would have used the ALLOW-FROM uri directive to allow from this other domain, but this directive is no longer recommended, is there an alternative to ALLOW-FROM uri that will enable me to simply add a domain that can be allowed to display iframe content?
For all browsers except some older ones (like IE) you should use Content-Security-Policy with the frame-ancestors directive instead. With CSP frame-ancestors you can use wildcards *.domain.com or multiple sources "oldapp.domain.com api.domain.com www.domain.com".
X-Frame-Options ALLOW-FROM only accepts one uri, you will likely have to dynamically set the uri from a list of allowed hostnames based on the incoming request. Alternatively you can set the value to SAMEORIGIN if you don't need to fully support IE and other outdated browsers as X-Frame-Options will be disregarded if CSP frame-ancestors is present.
I have a CSP with the following line in it:
script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http: https://static.cloudflareinsights.com https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/email-decode.min.js;
and I can see that the CSP is correct in the response header for the page.
I am still getting a [Report Only] Refused to load the script https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/email-decode.min.js error.
Cloudflare is auto-injecting this script tag and so I cannot rely on the strict-dynamic property to cover it for me, nor can I add a nonce.
Is this failing because of scrict-dynamic overriding the fixed url in the CSP? We need strict-dynamic within the app, but we also need to allow a custom whitelist url for these situations.
Any ideas?
Edit: Specifically I think the issue is cloudflare here. How is it possible to allow cloudflare to inject scripts, while at the same time having strict-dynamic set? You cannot give cloudflare a nonce, and strict-dynamic will not let you white-list so how is it possible to overcome this?
If you use strict-dynamic, it ignores the allow-listed domain. That's why that approach isn't working.
BTW, you can't use a full URL like http: https://static.cloudflareinsights.com https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/email-decode.min.js anyway. You can only use https://static.cloudflareinsights.com https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/.
BTW, you may find https://csp-evaluator.withgoogle.com/ helpful for finding problems like that in your CSP. (I'm not affiliated with them. I just think it's useful.)
At the end of the day, Cloudflare is going to need to fix this on their side. They see your CSP in your response. They need to make use of your nonce. They do this sometimes. If you read https://developers.cloudflare.com/bots/reference/javascript-detections/, it says, "If your CSP uses a nonce for script tags, Cloudflare will add these nonces to the scripts it injects by parsing your CSP response header."
I want to block my site in the <iframe> tag. On research I found that to do so, I need to set the header as 'x-frame-options' to 'SAMEORIGIN'.
Tried setting the meta tag as
<meta http-equiv="X-Frame-Options" content="deny">
But this method is outdated since April 2016.
When I am trying to search it is giving me the result for httpClient.
But I want the same when Someone hit my url through .
Do I need to set the header through node or need to do some changes in angular.json
My site is working on node server with URL http://localhost:4200/.
You cannot do it on angular side, only on server side.
I think you can use this npm package:
https://www.npmjs.com/package/x-frame-options
If you are using any webserver like Nginx, Apache HTTP Server
example for how to use in Nginx
add_header X-Frame-Options "SAMEORIGIN";
in global scope, or location scope.
Better to do in location scope. Because, as soon as you add some header in location scope, the global scope will not reflect
Additional
You can take care of more things using the header like cross-site scripting
add_header X-XSS-Protection "1; mode=block";
Even though nowadays browsers are helping to reduce cross-site scripting. More detail description in here
Content Security Policy specification says
The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.
So from my understanding if both Content-Security-Policy and X-Frame-Options headers are present, then X-Frame-Options should be ignored.
I have a web app with both headers, and looks like Firefox 38 is ignores Content-Security-Policy header and uses X-Frame-Options header instead.
My sample headers are:
Content-Security-Policy:frame-ancestors 'self' local.com *.local.com
X-Frame-Options:Allow-From http://local.com
I want that my frame should be accessed from local.com and all subdomains. Local.com is just example. If X-Frame-Options header is present, then it allows just http://local.com, but if i remove it, then Firefox uses Content-Security-Policy header and works fine for domain and subdomains.
Does it mean that Firefox isn't implementing this part? Or it's just too new specification and Firefox doesn't implement it yet? Is there any other way to force Content-Security-Policy header usage?
I know that Chrome works fine with Content-Security-Policy and IE can work just with X-Frame-Options, but looks like i can't combine both headers, as Firefox works not in right way.
One possible way is to sent X-Frame-Options just for IE, and Content-Security-Policy for all other, but is there a better way?
Thanks!
frame-ancestors only appeared in CSP Level 2 (see the changelog) so it's very likely that Firefox 38 just hasn't implemented it yet.
You can verify that quite easily by watching the JavaScript console - the browser will display warnings about each of the CSP directives it doesn't understand.
You can also download Firefox from the beta channel and see if it makes difference, but obviously it won't help much if you just want to build a interoperable solution for production website...