I'm supporting a legacy asp.net portal which has inline scripts and css in it.
We are using content-security-policy custom header with script-src 'self' 'unsafe-inline'.
Right now we are facing issue in loading some RDL in chrome browser alone. If I remove the content-security-policy header, RDL is loading properly across all browsers.
Any suggestions that I should remove the custom header or any changes I should do in the custom header inorder to load the RDL across all browsers.
Related
I wrote a Java WebApp using Tomcat Version 9.0.69 and Wicket 9.12.0 plus Chrome Version 109.0.5414.75 for display, but CSP (Content-Security-Policy) totally messes up the display with a bunch of "Refused to [load the stylesheet/script '' | apply inline style] because it violates the following Content Security Policy directive: ...".
I tried to use HTML metas like "", it failed.
I tried to configure CSP inside Tomcat config, it failed too.
The only way right now I can see my web application properly is by using a Chrome plugin to disable CSP for the display tab.
I would like to fix this issue at the source, where is strict CSP policy defined here, Tomcat, Wicket, or Chrome?
I tried to fix CSP in HTML metas and Tomcat config, no effect.
Only disabling CSP in Chrome with a plugin worked to nullify CSP effect.
Some CSP related settings are defined in Wicket.
If you use the quickstart Maven archetype then they are in WicketApplication.java
You could disable them by replacing these lines with:
getCspSettings().blocking().disabled();
I made a chrome extension that loads an iframe on the gmail url. So far so good!
When I install the extension it loads the I framed with no problems but here comes the problem. If I refresh or access gmail again it doesn't work anymore with the following error, and no other errors.
Refused to frame 'https://...........com/' because it violates the
following Content Security Policy directive: "frame-src 'self'
https://clients4.google.com/insights/consumersurveys/
https://calendar.google.com/accounts/ https://ogs.google.com
https://onegoogle-autopush.sandbox.google.com
https://accounts.google.com/ https://apis.google.com/u/
https://apis.google.com/_/streamwidgets/
https://clients6.google.com/static/
https://content.googleapis.com/static/
https://mail-attachment.googleusercontent.com/
https://www.google.com/calendar/ https://calendar.google.com/calendar/
https://docs.google.com/ https://drive.google.com
https://.googleusercontent.com/docs/securesc/
https://feedback.googleusercontent.com/resources/
https://www.google.com/tools/feedback/
https://support.google.com/inapp/
https://.googleusercontent.com/gadgets/ifr
https://hangouts.google.com/ https://talkgadget.google.com/
https://.talkgadget.google.com/
https://www-gm-opensocial.googleusercontent.com/gadgets/
https://plus.google.com/ https://wallet.google.com/gmail/
https://www.youtube.com/embed/
https://clients5.google.com/pagead/drt/dn/
https://clients5.google.com/ads/measurement/jn/
https://www.gstatic.com/mail/ww/ https://www.gstatic.com/mail/intl/
https://clients5.google.com/webstore/wall/
https://ci3.googleusercontent.com/ https://workspace.google.com/u/
https://workspace.google.com/marketplace/appfinder
https://gsuite.google.com/u/
https://gsuite.google.com/marketplace/appfinder
https://www.gstatic.com/mail/promo/ https://notifications.google.com/
https://tracedepot-pa.clients6.google.com/static/
https://staging-taskassist-pa-googleapis.sandbox.google.com
https://taskassist-pa.clients6.google.com
https://.prod.amp4mail.googleusercontent.com/
https://.client-channel.google.com/client-channel/client
https://clients4.google.com/invalidation/lcs/client
https://tasks.google.com/embed/ https://keep.google.com/companion
https://addons.gsuite.google.com
https://contacts.google.com/widget/hovercard/v/2
https://gsuite.google.com
https://.googleusercontent.com/confidential-mail/attachments/".
Now. You are wondering if I put the CSP in my header. The answer is yes. I have header("Content-Security-Policy: frame-src 'self' https://*.google.com;"); in my php and the header si loaded. But the question I can't answer is: Is Chrome seeing errors after the page refresh and why?
In theory if there is a problem in the CSP it should block the iframe from the first moment, and not after a while.
Do you know anything about this?
Refused to frame 'https://...........com/' because it violates the
following Content Security Policy directive: "frame-src 'self' ... Google's domains here ...
It's not your CSP, but some of Google's iframe publish its own. Because commonly Google does not allow to embed own into third-party.
Most interesting part: 'https://...........com/' is hidden (is here your domain or not?).
Is Chrome seeing errors after the page refresh and why?
Google's services based on a lot of it own iframes, wich inter each other based on Cookie.
For example, you can embed https://gmail.com into iframe, but if you are logged into account (have auth Cookies), Gmail does auto redirect you to https://mail.google.com/mail/u/0/ page which does not allow iframing (because of X-Frame-Options deny).
Behavior of iframes of Google could be very complicated, so a exact answer "Why" is not possible without detail researches.
Anyway embed of Google services (not officially intended for embedding) into iframe is not a good idea. Google does not allow that because of security.
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)
I am trying to make existing IE5 web-portal compatible with IE11.
It is written in "Enhanced Perl-parsed HTML" (*.ephtml) and seem to work in IE11 well with "Compatibility View Settings" turned on.
Unfortunately solution should work without any configuration on user side.
I found that Compatibility View can be turned on by adding tag:
<meta http-equiv="X-UA-Compatible" content="IE=5" />
without any changes on client side.
And that Apache can be configured to add this tag to every page using
LoadModule headers_module modules/mod_headers.so
Header set X-UA-Compatible “IE=IE5”
in httpd.con
(https://msdn.microsoft.com/en-us/cc817573.aspx)
(Adding an http header site wide in php)
This doesn't solve problem entirely, since many of the portal pages are mage up from frames and this header isn't being inserted into frame pages.
Therefore many pages with frames are broken (but work correctly if Compatibility View is turned on Browser Wide)
Is there any way to add this header automatically to all frames using Apache configurations?
Only other solution I can see right now is modifying all the pages, manually inserting this header.
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.