I have a code that I save on an iis site on my server.
I want to approach it using iFrame from 2 other hosts.
It works from one host but not from the other one.
It works fine from a host that starts with HTTP but not from the one that starts with HTTPS.
I added the "HTTP Response Header" properties with name: Content-Security-Policy and value: "frame-ancestors http://www.rabincenter.org.il https://www.rosh-hanikra.com; form-action 'self' http://www.rabincenter.org.il https://www.rosh-hanikra.com".
The iFrame that does not work displays the error message: "myCode sent an invalid response.".
Am I doing something wrong? Can someone give me a hand?
Thank you in advance
Related
I have an asp.net MVC5 app deployed in a IIS server and running from http://x.x.x.x/app. I have a view called Geocatalog which contains an iframe in where I want to embed Geonetwork(deployed in tomcat9) which runs in the same server (http://x.x.x.x:PORT/geonetwork) but when executing in the navigator I have this error :
Refused to frame 'http://x.x.x.x:PORT/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'none'".
I don't know why is this happening? I did the exact same thing with another url and it worked well.
Update :
In my web.config file I added this line :
<add name="Content-Security-Policy" value="frame-ancestors http://subdomain.domain.com" />
Still no changes noticed
Your help would be appreciated.
CSP spec does not allow to use IP address as host-source, except 127.0.0.1 only.
Therefore you need to use domain name instead of IP in <iframe src='x.x.x.x' and in frame-ancestors as well.
If you specify hostname with scheme like http://example.com it means the default port 80 to be allowed only (or 443 for https:).
If you use non standard port number you should to specify it exactly:
frame-ancestors http://subdomain.domain.com:12345 or frame-ancestors subdomain.domain.com:12345. The last one will allow iframing with the same scheme as parent page loaded and avoid block mixed content. But you should use multi-scheme URI: <iframe src='//subdomain.domain.com:12345' in this case.
I'm trying to make a request from postman to keycloack for authorization test and still getting this error:
{
"error": "invalid_request",
"error_description": "You must provide the issuedFor"
}
PostMan request parameters:
Postman bearer token header:
I know you've already picked an answer, but for the ones landing here from a web search on the Keycloak's issuedFor problem.
The root cause of the error message shown is the typo in the parameter name "audience" (not "audiance)". That nowadays would make Keycloak to fail fetching the client ID at https://github.com/keycloak/keycloak/blob/3631618b245fa768bff7009b9e87d01dd4387fe3/services/src/main/java/org/keycloak/authorization/authorization/AuthorizationTokenService.java#L330. Just fix the spelling and you should be fine.
For the record, the "audience" parameter is required in the requests to evaluate permissions as stated in the Keycloak's documentation for the Authorization Services: https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_obtaining_permissions.
Ook i found the problem and resolved it. Keycloak does not give access to some type of requests when going out of the network. You must put it in https. When on your local machine, it does work but as soon as you go out of localhost to the network to reach keycloak, you must pass to https.
So what i did is, in my request url, i changed the link to keycloak from http to https and hence changed the port from 8080 to 8443 (the port for https serving). Hope it would help someone. Special thanks to #RossPresser :)
I have a Jira instance running under nginx and we have some CSPs configured in nginx.
Now we are installing an app that generates links that trigger a browser extension, the URLs start with goedit:
The vendor of the app suggests this CSP header:
add_header Content-Security-Policy
default-src https: goedit: wss: 'unsafe-inline' 'unsafe-eval';
img-src https: data: 'unsafe-inline'" always;
I am now trying to incorporate this into our CSP header.
Our CSP Header includes
frame-src '' https://assets.zendesk.com https://www.facebook.com https://$server_name;
When I now click on one of the Links for that app I get this error message in the console:
Refused to frame '' because it violates the following Content Security Policy
directive: "frame-src https://assets.zendesk.com https://www.facebook.com https://my-server.dein-james.de".
I am wondering: What do I need to put into the frame-src to allow this kind of link ('')?
I'd rather not drop the whole frame-src part, I want to keep those whitelisted.
thanks in advance
Jens
I know this is quite an old thread now but I came across a similar issue today. With mine I was using data: in the object-src and I had to ensure data: was then in the frame-src.
Therefore I would check that in frame-src you include any schema's, I suspect it might be the goedit: or wss: in your example?
Though this is old, I found that:
Stefan's solution works.
I had a situation where dynamic iframes (meaning, an iframe added dynamically) were attempting to load a pdf for nice display (in chrome), and though the scp contained "self" for frame-src, and the pdf was from the current domain, some users couldn't see the content, their consoles showed the above error. After messing around, found that simply there is a setting to tweak in the chrome browser - go into the settings, search "pdf" and find the section where you can toggle for pdf the setting that makes pdf's download automatically, vs display in the browser.
I am stuck. I can't get the google analytics (and other external scripts for that matter) running.
Here's what I did in nginx:
server {
# other stuff
location = /mylocation {
add_header Content-Security-Policy "script-src 'self' 'unsafe-inline' 'unsafe-eval' www.google-analytics.com";
}
}
I've attached a screenshot to show that this header information is actually received by the browser (i.e. in this case it's Firefox).
So the script should be executed but it isn't.
In the Console I am getting (translated from German the actual English error message will propably be different):
"Content Security Policy: the settings of the page have blocked loading of a resource on https://www.google-analytics.com/analytics.js ("script-src")"
What's wrong with my policy settings?
So after banging my head against the wall for hours and even telling my customer that I manufactured a broken functionality it turns out the problem was an add-on I had installed on my dev machine's firefox. Finally found the solution here:
Strange CSP error in Firefox
I have a company website that's hosted as https://foo.bar.com.
However, it was incorrectly conveyed to a lot of users that the URL would be www.foo.bar.com. Until this can be rectified, we are putting through an interim solution by setting up a proxy site www.foo.bar.com that will redirect any users coming to it to https://foo.bar.com.
This works... but only the first time the user navigates to the page. The next time I try to access www.foo.bar.com, due to caching, the browser takes me to https://www.foo.bar.com. We don't have a certificate set up for https://www.foo.bar.com and as a result are given a NET::ERR_CERT_COMMON_NAME_INVALID error.
Is there a way to work around this without needing a certificate?
To test, I've even tried returning a webpage when the I navigate to www.foo.bar.com with a link that navigates to https://foo.bar.com. However, the same issue happens even in this case. I'm guessing HSTS is at play here but not sure how to go about it.
I'd appreciate any insight into this matter, thank you in advance.
I belive the only solution to your problem is to obtain a valid certificate for www.foo.bar.com. Due to the certificate error the browsers will not attempt to communicate with your server so there's no way for you to issue a redirect away from wrong domain to the correct domain.
Why only the second time?
You mention HSTS so I am assuming https://foo.bar.com is sending a Strict-Transport-Security header as part of it's response. This header likely is being sent with the includeSubDomains option which instructs the browser to not only enforce HTTPS on foo.bar.com but also all subdomains of that main domain. As a result, when trying to request www.foo.bar.com the browser matches that HSTS rule and automatically re-writes it to use HTTPS.
Once this HSTS rule has been set in the browser it cannot be removed except by expiring, either by exceeing the original max-age time or by issuing another Strict-transport-security header with max-age=0 on https://foo.bar.com