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 :) ).
Related
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.
In MDN HTTP Strict Transport Security (HSTS), it has an example of HSTS settings as below
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
where I can find the corresponding mean of max-age and includeSubDomains in RFC 6979, but it does not have the meaning of preload.
I have tested in latest Chrome and Firefox, and it seems that preload does not do anything at all. With and without preload, on requesting http request, both trials if using Chrome, can find 307 Internal Redirect made by Chrome browser without requesting to the server, which is what HSTS expect.
So what is the purpose of preload?
In addition, even if I add HSTS header, it will still have a chance to be attacked, on the first time the user visit the website with HTTP. How can we mitigate from this risk? That is, how can we tell the browser to add the domain to HSTS list before any request are sent to the server?
P.S.
I have found https://hstspreload.org/, which if I need to register the domain, requires me to add max-age and preload directive. Is it the reason why preload is necessary? And this should be the page where I should add my domain to ensure new user are safe from SSL Stripping Attack?
Preload is a big commitment. It will effectively be hardcoded into a browser’s code. Given it takes several months at a minimum to roll out new version, it’s basically irreversible.
Also as it’s down at the domain level, mistakes have been made. For example preloading domain.com but covering that blog.domain.com, or intranet.domain.com have not been upgraded to HTTPS. At this point your options are 1) upgrade side to HTTPS and live with zero users to the site until the or 2) reverse the preload and wait the months for that to roll out to all browsers and deal with zero users until then.
HTTPS is much more common now, so the risks are reduced but when HSTS preload first came out, these were real risks.
Therefore the preload attribute was a signal that the site owner was ready for that commitment. It also prevent someone else submitting a site that wasn’t using this header (whether maliciously or with good, but misguided, intentions).
You are correct in that it doesn’t “do” anything in the browser.
There was also talk of checking if the preload header was still being sent, and if not removing the preload but not sure if that’s done.
The HTTP page at my website sends an HSTS header. This has no effect over HTTP, and should be removed. But what if i decide to not remove the error and preload my website through the HSTS Preload form? What happens?
Don’t think there’s any preload requirement over this so still should be able to preload.
However if you can’t follow the spec on how to use HSTS, and can’t figure out how to prevent this being illegitimately sent over HTTP (which could have been researched in the time it took to raise your question), then I’d really question whether you are ready for the commitment that preload binds you to. There are real dangers when preloading without understanding the full implications as it’s basically irreversible.
I have been looking for a way to make sure my web server is secure against a man in the middle attack. It does seem that Google Chrome and Firefox work in blocking requests to my server even if I select to advance after the security warning. I am testing this by using Charles Proxy to intercept Https traffic without having trusted the Charles Cert on my Mac.
When I run the same tests with Safari it will let me through if I chose to ignore the secure warning, which I expect a certain number of users to do. So it seems there is more configuration needed to lock down Safari traffic. I know this is possible because when trying to navigate to github.com with the same scenario I get the following message:
Does anyone know what GitHub is doing to block Safari traffic on an untrusted connection?
Looks like Safari is supporting HSTS and that github is using it. Their HTTP response contains the following header:
Strict-Transport-Security:max-age=31536000; includeSubdomains; preload
This way a browser supporting HSTS knows that for the foreseeable time this site should only be visited with https and any attempts to use http only will automatically be upgraded by the browser.
Apart from basic HSTS which only works after the first visit of the site github also adds the preload directive. This tells browser makers that github likes to be included in the preloaded HSTS list shipped with the browsers, so that the browser applies HSTS even if the site was never visited before by the user. See HSTS Preloading for more information.
We have our site integrated as an iframe into another site that runs on a different domain. It seems that we cannot set cookies. Has anybody encountered this issue before? Any ideas?
Since your content is being loaded into an iframe from a remote domain, it is classed as a third-party cookie.
The vast majority of third-party cookies are provided by advertisers (these are usually marked as tracking cookies by anti-malware software) and many people consider them to be an invasion of privacy. Consequently, most browsers offer a facility to block third-party cookies, which is probably the cause of the issue you are encountering.
From new update of Chromium in February 4, 2020 (Chrome 80).
Cookies default to SameSite=Lax. According to this link.
To fix this, you just need to mark your cookies are SameSite=None and Secure.
To understand what is Samesite cookies, please see this document
After reading through Facebook's docs on iframe canvas pages, I figured out how to set cookies in iframes with different domains. I created a proof of concept sinatra application here: https://github.com/agibralter/iframe-widget-test
There is more discussion on how Facebook does it here: How does Facebook set cross-domain cookies for iFrames on canvas pages?
IE requires you to set a P3P policy before it will allow third-party frames to set cookies, under the default privacy settings.
Supposedly P3P allows the user to limit what information goes to what parties who promise to handle it in certain ways. In practice it's pretty much worthless as users can't really set any meaningful limitations on how they want information handled; in the end it's just a fairly uniform setting acting as a hoop that all third parties have to jump through, saying “I'll be nice with your personal information” even if they have no intention of doing so.
Despite adding SameSite=None and Secure in the cookie, you might not see the cookie being sent in the request. This might be because of the browser settings. e.g, on Brave, you have to explicity disable it.
As more and more people are switching to Brave or block third party cookies using browser extensions, you should not rely on this mechanism.