I am using the below policy. It is not reporting passive mixed content like images loaded using http by a page in iframe.
default-src https:; report-uri <https reporting endpoint>;
Apparently, block-all-mixed-content directive also doesn't work: https://github.com/w3c/webappsec-csp/issues/26
Tried a more detailed policy like in https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet#Mixed_Content_Policy with img-src https: data: as well. But that doesn't work too.
Is it that CSP reporting doesn't work for passive mixed content?
CSP does not "trickle down" to pages loaded in an iframe, it applies only to the resource it was delivered with. If you want to declare a CSP for the page in the iframe, you'll have to include a CSP header for that page too.
Related
I'm trying to load my content into an IFrame, so I implemented the Content-Security-Policy header: Content-Security-Policy: frame-ancestors http://*.example.com/abc.html.
I am able to load the content on iframe when I give the header as
Content-Security-Policy: frame-ancestors http://*.example.com/.
But when I change the header to:
Content-Security-Policy: frame-ancestors self http://*.example.com/abc.html.
then the content on iframe is getting loaded for the first time but gives below error when I refresh the web page
Refused to display 'https://....' in a frame because an ancestor violates the following Content Security Policy directive: frame-ancestors self http://*.example.com/abc.html.
Can anyone tell why its giving error on refreshing the page.
Also does frame-ancestors considerers the full url (http://.example.com/abc.html) or only the hostname like http://.example.com?
Chrome browser has a bug - it's not support paths in the frame-ancestors directive. Safari nas the same bug, and only lasets Firefox supports paths in this directive.
So for frame-ancestors instead of http://.example.com/abc.html you have to use http://.example.com host-source.
For other directives you can use paths and filenames.
Without a working example it is hard to know exactly what the problem is. But based on the specification, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors, some adjustments to your CSP can be advised:
Remove the path, it is not according to the specification to use more than the scheme, host and port.
Use the expected scheme (http/https) or remove the scheme.
Use wildcard https://*.example.com, not just https://.example.com
Use 'self', not self
If the user has no activity(mouse, keyboard) in some period of time, API'S not working, I inspected and went to the network tab and found CSP is blocking.
Attempt:
<meta http-equiv="Content-Security-Policy"
content="default-src 'self';script-src 'unsafe-hashes' 'unsafe-inline' 'my-urls' ;">
Tried by adding meta link, but it's not working.
Since you observe CSP blocking, you already have a CSP published in the page. You can't relax this CSP by publishing a second CSP in meta tag, you need to edit a first one.
You can check what CSP your already have in browser, a tutorial is here.
XHR requests are covered by connect-src directive, therefore you have to add connect-src 'self' or connect-src https://your_domain.com if you perform connect to a site's own domain.
But first check a "Console tab" - it should be a CSP violation message like:
Refused to connect to wss://example.com/ because it violates the following Content Security Policy directive ...
Refused to connect to https://example.com/ because it violates the following Content Security Policy directive ...
You need to verify that wss://example.com/ or https://example.com/ is your legitimate domain, because this can be antics of some browser plugin or third-party iframe on page.
After thar you can add wss://example.com/ or https://example.com/ (depending what is blocked) into connect-src directive.
I am trying to add CSP to our web site, using report-only (to report-uri.com).
It seems to work as expected for most cases, but google related sites gets reported even if the URL is added to the header.
Here´s the relevant part of header as it appears in developer tools:
connect-src 'self' https://stats.g.doubleclick.net
I am still getting this violation:
"blocked-uri": "https://stats.g.doubleclick.net/j/collect"
I have experienced similar issues with other Google related sites as well.
The problem is that we're using Google tags and analysis, so I cannot block the sites out.
This particular problem seems to come from Chrome only.
In addition to blocked-uri, note in the reports on the original-policy field - is there your CSP with the connect-src 'self' https://stats.g.doubleclick.net rule or not.
Looks like some ISPs, in violation of RFCs, cache site responses along with HTTP headers. At least after the changes in the CSP, within 2 weeks there is violation reports having the old CSP in the original-policy field.
And it feels like you changed the rules in connect-src directive recently.
List of sources connect-src 'self' https://stats.g.doubleclick.net is not complete for Google Analytics, you can insert own Google Analytics ID and check. Here is comprehensive test of Content Security Policy for GTM.
Here is initial CSP for GA + GTM. The initial because though GTM you can embed a lot of third-party scripts from vary sources.
I need to relax the CSP (Content Security Policy) in Chrome to enable a redirect with some get parameters to the Azure login page. When processing such redirects Chrome applies policy restrictions related to form submissions. The default policy in such cases amounts to
<meta http-equiv="Content-Security-Policy" content="form-action 'self' javascript:"/>
In this case the redirect to https://login.microsoftonline.com/...
wont' work. The MDN says that you can expand the list of allowed destinations, which I tried like so:
<meta http-equiv="Content-Security-Policy" content="form-action 'self' https://*.microsoftonline.com javascript:"/>
It appears to have no effect at all as still get the same error on the console:
Refused to send form data to 'https://login.microsoftonline.com' because it violates the following Content Security Policy directive: "form-action 'self' javascript:"
Note also that playing with the order of the attributes or removing the javascript: part does help. However, removing the self part is evidently paid some attention to by Chrome as in this case I'm not able to send data back to the origin. It is almost like they let you tighten up the policy but not relax it.
Any help will be greatly appreciated.
I think that it is caused because form-action (according to the documentation):
The HTTP Content-Security-Policy (CSP) form-action directive restricts the URLs which can be used as the target of a form submissions from a given context.
Maybe you could try the default-src directive:
default-src
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives.
Hope it helps!
Do not include the protocol (https) and i think it will work
I'd like to open an HTTP Iframe inside an HTTPS page. Of course this is not normally possible as it will trigger an 'mixed-content' violation.
Is there any way to by-pass a mixed content block using "Content-Security-Policy" and hash sources ?
Example:
http://mysite/my-frame.html has an sha-256 hash of sha256-xxxyyy....zzz
https://mysite/index.html will be served with a Content-Security-Policy header as follow (or inlines an equivalente <meta> tag) as long as CORS headers:
Content-Security-Policy: frame-src sha256-xxxxyyyy....zzz
https://mysite/index.html includes an <iframe src='http://mysite/my-frame.html'>
Will this work ? Is there any other method to make this possible.
note: No upgrade-insecure-requests will not work because the page is a navigational request AND the frame HAS to be served from HTTP.
No, there's no way to bypass the security block on modern browsers (starting from Firefox 23, Chrome 14, IE9)
Thankfully, most modern browsers block this type of dangerous content
by default
ref: https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content#mixed-content-types--security-threats-associated
What if the server sets the csp child-src to http://mysite/my-frame.html? As I read the definitions it should work.
child-src lists the URLs for workers and embedded frame contents. For example: child-src https://youtube.com would enable embedding videos from YouTube but not from other origins. Use this in place of the deprecated frame-src directive.
https://www.html5rocks.com/en/tutorials/security/content-security-policy/