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.
Related
Is it necessary to apply the Content-Security-Policy Header to all resources on your domain (images/CSS/JavaScript) or just web pages?
For example, I noticed that https://content-security-policy.com/images/csp-book-cover-sm.png has a CSP header.
It is only necessary to apply it to web pages that are rendered in a browser, as CSP controls the allowed sources for content, framing etc of such pages. Typically you will only need to set it on non-redirect responses with content type as "text/html". As CSP can be set in a meta tag, another way to look at it is that it only makes sense on responses that could include a meta tag.
As it is often simpler or only possible to just add a response header to all responses, CSPs are often applied to all content types and codes even though they are not strictly needed. Additionally it is recommended to add a CSP with a strict frame-ancestors to REST APIs to prevent drag-and-drop style clickjacking attacks, see https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#security-headers.
It seems setting X-Frame-Options to deny is the most recommended method to prevent my website from being Iframed. But it is not perfect. First off X-Frame-Options can be ignored by using a Chrome extension as discussed in the below post. I have proved this is the case by using the Ignore X-Frame headers chrome extension.
Getting around X-Frame-Options DENY in a Chrome extension?
Secondly X-Frame-Options deny only works on the first iframe of a web page, if I iframe a web page twice the second iframe works.
My question is, what is the best multipronged approach to prevent my website from being iframed?
X-Frame-Options is just a response header. Of course if you control the client, you can ignore it. If you control the client, you can do pretty much anything.
The point in X-Frame-Options is to prevent attacks like Clickjacking (primarily) or Pixel Perfect Timing Attacks for example. It does indeed prevent those attacks, because the attacker cannot control the victim's browser to say install an extension (or if he can, Clickjacking is the least issue from the victim's perspective :) ).
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/
I am working on addition of Content-Security-Policy-Report-Only header to my company's website. While I was researching on it, I found that a few of the pages already have Content-Security-Policy header set.
I investigated further and found that the directives are not required. Also, default directive used for those pages is 'self' whereas what I am planning to set for report-only is 'https:'
I am not an expert in this area and want to make sure that both header values don't interfere. Hence looking for guidance
If I set report-only for the pages that already has CSP header, is it going to interfere with existing headers? Is the behavior browser dependent?
Any help/pointers will be helpful in deciding.
Thanks!
Content-Security-Policy and Content-Security-Policy-Report-Only have no effect on each other and are entirely independent. Setting both is a common practice when tightening policies. I wouldn't doubt that there has been a bug around this behavior at some point, but the spec is clear.
From Section 5 of the CSP2 Spec
A server MAY cause user agents to monitor one policy while enforcing another policy by returning both Content-Security-Policy and Content-Security-Policy-Report-Only header fields. For example, if a server operator may wish to enforce one policy but experiment with a stricter policy, she can monitor the stricter policy while enforcing the original policy. Once the server operator is satisfied that the stricter policy does not break the web application, the server operator can start enforcing the stricter policy.
Based on the link here, server must not send both headers in the same request.
Here is the original text: A server MUST NOT provide Content-Security-Policy header field(s) and Content-Security-Policy-Report-Only header field(s) in the same HTTP response. If a client received both header fields in a response, it MUST discard all Content-Security-Policy-Report-Only header fields and MUST enforce the Content-Security-Policy header field.
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...