Mixed Content , Content-Security-Policy and hash-source - content-security-policy

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/

Related

What is the current protection on an iframe site?

In different site I see different data about what mechanism protects against inserting an iframe.
Tell me, is it possible that these are different levels of protection or are some of these outdated mechanisms?
Same-origin policy prohibits opening an iframe of another domain
At the same time, there is a Content-Security-Policy with the frame-ancestors directive
And there is also X-Frame-Options: DENY
No, the Same-Origin Policy, by itself, doesn't prevent you from framing a document from another origin.
X-Frame-Options and CSP's frame-ancestors directive overlap as defences against cross-origin framing. Only the former is supported in old browsers, though. However, the latter is much more flexible. Also, in case both are present in a response, frame-ancestors takes precedence over X-Frame-Options in supporting browsers.
Finally, don't forget that you can sandbox an iframe in order to further isolate the framing document from the framed document.

content-security-policy doesn't work; I want to have my website load in an iFrame on ONE other website only

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.

content security policy frame-ancestors

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

CSP report-only doesn't report passive mixed content?

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.

X-Frame-Options and Content-Security-Policy for frames in Firefox

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...

Resources