I have a very old site built in ASP .Net 2008 by an external team who I have no contact with. All of a sudden a page doesn't seem to render properly in Chrome and FireFox but works fine with other browsers. The page is set with an iFrame.
Looking under Inspect Element (Chrome) for the page failing to render I see the error
Refused to display 'http://www.example.com/somepage.html' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN, SAMEORIGIN'.
So read a few articles and I may not understand this fully but it seems to me the error is, the domain requested will NOT allow itself to be displayed within a frame.
The URL above is not the URL I am familiar with (i.e. its third party, I don't have any control with it). Is there anyway to resolve this or is this purely the owner of the domain would have to allow? IF so why does it work in other browsers?
Is there anyway to resolve this
Not at your end.
or is this purely the owner of the domain would have to allow?
This
IF so why does it work in other browsers?
Speculating a little here, but SAMEORIGIN, SAMEORIGIN is not a valid value. It looks like Chrome is attempting error recovery and treating it as SAMEORIGIN
Quentin answer summaries it well.
In addition, if it is an external site beyond your control, they may have good reasons to forbid framing. (Like preventing click-jacking.)
They may also have included a Content-Security-Policy:frame-ancestors 'self' header which would have the same effect.
(And currently, a bug in Chromium (and Chrome) causes X-Frame-Options to take precedence over Content-Security-Policy while it should not.)
You may hack that if their site is served over http (not https) and you have control of a common network device through which all your users network traffic to this site must go. I mean, on that device, if it does allow you to do so, you may filter out 'undesired' headers from responses of this site.
Of course, this is a debatable hack. Depending on terms of uses of the 'victim' site, it could even be a legal issue to do so.
Related
Can I embed a Microsoft Teams video meeting into my website using an iframe or other technology?
When I tried, I got this error:
Refused to display 'https://teams.live.com/' in a frame because it set
'X-Frame-Options' to 'sameorigin'.
Can it be cheated somehow?
No you can't. The error message is telling you exactly why not: Microsoft have set a HTTP header in the Teams site which instructs the browser not to load the page into any kind of frame unless that frame is within the teams.live.com website.
The MDN documentation for X-Frame-Options says
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
This is not something you can override - if you could, setting the header would immediately become completely pointless, since anyone with malicious intent would simply choose to ignore it.
Good day everyone.
So I have a website and I am trying to embed in an iframe a dynamics server and it keeps throwing an error something about
'Refused to display https://XXXXXXXXXXXX in a frame because it set 'X-Frame-Options' to 'deny'.
Any ideas how I can get it to work?
This happens when we try to redirect the page to a login page.
Thanks
Check X-Frame-Options hearder:
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 clickjacking attacks, by ensuring that their content is not embedded into other sites.
Based on the above statement, this is something that the 'https://XXXXXXXXXXXX' has added to the page to disallow it from being used as an <iframe>
You can see that this can even be configured globally on a web server level, to secure all the websites.
If the website is in the same domain the workaround is easier using SameOrigin value.
If you want to allow all, then just don't set the response header for the XXXXXXXX site at all (if you have access to it).
In Chrome 73.0.3683.103 console, as of today, I am seeing the following error:
The Content Security Policy 'script-src 'report-sample'
'nonce-PNYOS1z63mBa/Tqkqyii' 'unsafe-inline';object-src
'none';base-uri 'self'' was delivered in report-only mode, but does
not specify a 'report-uri'; the policy will have no effect. Please
either add a 'report-uri' directive, or deliver the policy via the
'Content-Security-Policy' header.
I believe this is from script src="https://apis.google.com/js/platform.js"... Everything seems to work. The initiator seems to be https://content.googleapis.com/static/proxy.html?usegapi=1...
What is causing this and how can I fix it?
Edit: As of today, I am no longer seeing the error. So I assume google has fixed this issue.
If the parent page is owned by you there's a couple of things you can do to correct this. If the parent page is not owned by you, there's nothing you can do, but this warning won't affect your experience.
First some background:
What is CSP?
A Content Security Policy or CSP is a header your server can set which tells the browser to enforce a whitelist of what content can run on your page, where it can come from, and how it can run. For example, you can limit what domains JavaScript is allowed to be fetched from, whether JavaScript can run inline, or where JavaScript can make xhr calls out to.
CSP can run in two modes: blocking and reporting.
In blocking mode the browser enforces the policy laid out in the CSP and applies those restrictions to your webpage. In blocking mode you can optionally have any blocked content be reported back to an endpoint you specify in the report-uri directive of the CSP. In reporting mode nothing is blocked only things that would get blocked get reported to the endpoint specified in the policies report-uri directive.
Your specific issue
The browser warning says that you're running in reporting mode but you haven't specified a report-uri so it doesn't know where to report violations. In effect, your CSP is doing nothing other than wasting bandwidth because it's not reporting or blocking any issues it's finding.
That leaves you with a few options:
Do nothing. Your CSP won't alert you about any issues (outside of messages in the console) and it won't block any content.
Add a report-uri (something like report-uri: https://example.com/csp_reports) to receive requests. Even if you're not receiving anything at that endpoint your specific console warning will disappear (you'll still get console errors for specific CSP violations even if they aren't blocked).
Switch the CSP into blocking mode. You won't receive any reports but the warning will disappear as the CSP now serves a purpose of blocking content. Caution don't do this if it's saying it's blocking a lot of things. That's indicative that your site might break. First, fix the issues it's blocking by adjusting the CSP or changing what resources you're using and then flip it into blocking mode.
Switch the CSP into blocking mode and add a report-uri. Long term, this is best solution from a security standpoint but the warning from step 3 applies.
If it was me, I would first add a report-uri to understand what warnings my page is generating (note some might be triggered by browser extensions - nothing you can do about that, but that's okay). Once I understand the common warnings I'd tweak the CSP and what resources I have to make sure the page is loading without any warnings or errors in the console. Then I'd switch the CSP into blocking mode to take advantage of the security benefits it provides.
This is related to the server/backend level settings.
If you have access to your server from where code is served, you can set the header settings. So currently Content-Security-Policy-Report-Only this has been set without all required parameters. You can just check there and either remove this header (if not required), or set the required parameters.
You can find the header details from here
I have an HTML page with an iframe included from a cross domain that doesn't belong to me.
I need to do some basic javascript modifications in the iframe (write value and fire up an event -> form processing).
Because of the same origin policy I'm not allowed to do this. However, I need to do it, so I'm searching for a workaround.
The solution is just important that I can run a script for myself. It is enough if it works in one browser and I don't need security for myself.
On my research I have found a lot of ways to break the same origin policy like document.location (in FF only with similar locations), JSONP/sendMessage (I need to be the owner of both domains) and so on, nothing that works with an iframe of a page that doesn't belong to me.
The only "workaround", if you can't make the other site include the relevant CORS headers, would be to fetch the iframe content server side and serve it as coming from your own domain.
The reason there isn't simpler workaround is due to why there is this same origin policy : to protect users.
We have application hosted "xyz:8080/rootapp" and cometd services hosted on "xyz:9090/cometed". The JavaScript loaded from cometd server needs to access the DOM/JavaScripts loaded from (xyz:8080), the browser's same origin policy is not allowing it.
To overcome it we set 'document.domain' as "xyz" eliminating port. This solution is working well but this is becoming problem to all the iframes loaded by "xyz:8080" and I need to change each and every iframe to use domain as "xyz".
Can someone provide me hints to solve this problem without changing each and every iframe?
Do we have any http header to set domain?
You can use CORS to specify an exception to same origin, this will work in any relatively modern browser.
This page has a fairly good intro and a list of compatible browsers.
The short version is put an Access-Control-Allow-Origin header into the responses from xyz:8080 that contains either xyz:9090 or * (for unrestricted access).