I need to have https://web.whatsapp.com embedded in my website via iframe. I get the error of X-Frame-Options. I use express server and I tried to configure it with helmet:
app.use(
helmet.frameguard({
action: "sameorigin",
})
)
Doesn't seem to work. Same with deny. I read that ALLOW-FROM is not supported in Chrome browser anymore. Is there any chance to bypass or allow X-Frame-Options to accept certain origins? (Maybe there is any other options how to embed https://web.whatsapp.com to my website?).
X-Frame-Options prevents a site from being framed. As web.whatsapp.com prevents framing, there is nothing you can do to allow it being framed, unless you proxy the connection and remove headers. Adding headers to the site framing the other won't change anything.
Related
So I'm trying to avoid using (another) page rule to disable Rocketloader for one of my subdomains, since we can't use a RegEx to select multiple specific subdomains under a single page rule, and only get 3 page rules for free accounts.
According to this page:
https://support.cloudflare.com/hc/en-us/articles/216537517-Using-Content-Security-Policy-CSP-with-Cloudflare
I can just add a header to the domain to allow scripts from CloudFlare:
add_header Content-Security-Policy "script-src 'self' ajax.cloudflare.com;";
I did so in the Nginx config for that subdomain (it's a Chronograph container actually), restarted Nginx, tested to make sure it "took", which it did:
But then when I try to load the domain, it won't load, and the inspector shows this:
Not being super familiar with this, does anyone know where I screwed it up?
where I screwed it up?
First of all, here:
I can just add a header to the domain to allow scripts from CloudFlare:
add_header Content-Security-Policy "script-src 'self' ajax.cloudflare.com;";
I did so in the Nginx config
And secondly, you trusted the report-uri service, but it failed you.
You have had an issue with ajax.cloudflare.com BEFORE adding CSP header into Nginx config (otherwise, why add it). This means that you already have a CSP published via an HTTP header or a meta tag <meta http-equiv= 'Content-Security-Policy'>.
By adding the CSP header to the Nginx configuration, you have added a second policy to the pages.
Multiple CSPs work as sequential filters - all sources must pass through both CSPs to be resolved. The second CSP allows ajax.cloudflare.com host-source, but the first one still prohibits it (that you are observe in the inspector).
You have to figure out where the first CSP is published and to add ajax.cloudflare.com into it, instead of publish second CSP.
No one know what is under the hood of the report-uri and how it will react if two CSP HTTP headers or an HTTP header paired with a meta tag are published simultaneously
Have a look which CSP and how many of them the browser actually gets, the guide is here.
In case of 2 CSP headers you will see something like that:
In case of CSP meta tag you can easily check the by inspecting the HTML code.
I think the report-uri just did not expect such a situation.
I have static content (icons etc...) served via Asp.Net
Every response gets caching added to it, like this:
Response.Cache.SetExpires(Now.AddMinute(30))
Response.Cache.SetValidUntilExpires(True)
When I browse from my office everything is fine
When one of the users browses from home, the icons are not cached. Which makes browsing very slow.
I have a log that shows the incoming requests, and the requests from this user have this header
"Cache-Control":"no-cache, no-store"
I don't know if that's the issue, and if yes, how can I solve it? Or can there be something else wrong?
Also, after setting the cache expiration, it seems that the Response.Headers are not affected. I don't see the caching info in the headers.
This is the header string. Not a word about caching.
{Server=Microsoft-IIS%2f10.0&HitID=9&X-AspNetMvc-Version=5.2}
Why are my Cache settings being ignored?
Please check your IIS cache setting. The static file setting may not related with the Response.Cache.SetExpires method().
And you can also set the Cache-Control in iis. About how to set the Cache-Control you can refer to this link.
Cache-Control
why google.com not set includeSubDomains directive on http strict transport security response header ?
google.com HSTS resonse header is something like:
Strict-Transport-Security:max-age=86400
Why not
Strict-Transport-Security: max-age=86400; includeSubDomains
The second one should be more secure from my side, is that right ??
It is static
Using Google Chrome, you can go to chrome://net-internals/#hsts and Query different domains. Entering google.com and clicking on Query will bring back a list of results.
In that result list, you can see that static_sts_include_subdomains is true and dynamic_sts_include_subdomains is false. This is better than setting it dynamically, which is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication. In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source.
Hope this helps
Yes it is more secure to use includeSubDomains.
For example an attacker could set up and use a subdomain (e.g. hacked.google.com) and access that over HTTP and and use that to access or override cookies set at top level domain (google.com) even though that top level domain is secured with HSTS. Of course if you're using Secure attribute on your cookies then this might not be an issue but this is just one example of why to use includeSubDomains.
You cannot set the includeSubDomains attrribute unless all subdomains are available on HTTPS (obviously). So if Google had blog.google.com and had still not upgraded this to HTTPS then that might explain why they would not use includeSubDomains at the top level domain.
However, as #Horkine rightly points out, Google preloads their domains into the Chrome browser code (and that preload list is also picked up by other browsers) so this HTTP header isn't used for modern browsers.
Weirldy there are some inconsitencies between the preloaded version and the HTTP HTTP Headers version. That is very odd to be honest. Incidentally these discrepancies also breaks their own rules for preloading.
www.google.com
The preloaded version for www.google.com does have the includeSubDomains attribute.
The Strict-Transport-Security HTTP Header version does not have the includeSubDomains attribute but not the preload attribute.
google.com
The preloaded version for google.com does have the includeSubDomains attribute
No Strict-Transport-Security HTTP header is published.
Why these inconsistencies? We can only guess:
It could be that they never got round to updating their HTTP Header after finishing the upgrade to all their sites?
Or it could be because some of the apps do browser detection for older browsers (which do not include the preload code, but does understand the HSTS header) and redirects older browsers to http://old.google.com for some reason?
Or it could be region specific?
All of it is a guess really, as only Google can answer and I'm not aware of any documentation of what they use on their own site or why.
But, yes, to answer you last question it is more secure to include includeSubDomains (if possible) and it is even more secure to preload (though not without risks unless you are 100% confident you are only using HTTPS).
Trying to publish HTTPS content (login form) using iframe onto HTTP page.
Have permission, but do not have access to source code of HTTPS page.
Standard attempts to publish iframe do not work with this HTTPS page content.
Appears that HTTPS page x-frame-option set to DENY.
Is there any way to embed/frame/etc. this HTTPS content onto HTTP page despite x-frame objections?
This is a WordPress site. Not sure if that is relevant here.
No there is not, and this actually have nothing to do with HTTP or HTTPS, it's how the X-frame-Options header works.
When a resource returns the header of X-Frame-Options: DENY, it is not possible to show it in any iframe or iframe-like window, not even one on the same site.
You said you have permission though, so perhaps you can get the service you are using to use the ALLOW-FROM option for your service. Something like this could be configured to allow your site to frame it.
X-Frame-Options: ALLOW-FROM https://example.com/
I am developing a web page that needs to display, in an iframe, a report served by another company's SharePoint server. They are fine with this.
The page we're trying to render in the iframe is giving us X-Frame-Options: SAMEORIGIN which causes the browser (at least IE8) to refuse to render the content in a frame.
First, is this something they can control or is it something SharePoint just does by default? If I ask them to turn this off, could they even do it?
Second, can I do something to tell the browser to ignore this http header and just render the frame?
If the 2nd company is happy for you to access their content in an IFrame then they need to take the restriction off - they can do this fairly easily in the IIS config.
There's nothing you can do to circumvent it and anything that does work should get patched quickly in a security hotfix. You can't tell the browser to just render the frame if the source content header says not allowed in frames. That would make it easier for session hijacking.
If the content is GET only you don't post data back then you could get the page server side and proxy the content without the header, but then any post back should get invalidated.
UPDATE: 2019-12-30
It seem that this tool is no longer working! [Request for update!]
UPDATE 2019-01-06: You can bypass X-Frame-Options in an <iframe> using my X-Frame-Bypass Web Component. It extends the IFrame element by using multiple CORS proxies and it was tested in the latest Firefox and Chrome.
You can use it as follows:
(Optional) Include the Custom Elements with Built-in Extends polyfill for Safari:
<script src="https://unpkg.com/#ungap/custom-elements-builtin"></script>
Include the X-Frame-Bypass JS module:
<script type="module" src="x-frame-bypass.js"></script>
Insert the X-Frame-Bypass Custom Element:
<iframe is="x-frame-bypass" src="https://example.org/"></iframe>
The X-Frame-Options header is a security feature enforced at the browser level.
If you have control over your user base (IT dept for corp app), you could try something like a greasemonkey script (if you can a) deploy greasemonkey across everyone and b) deploy your script in a shared way)...
Alternatively, you can proxy their result. Create an endpoint on your server, and have that endpoint open a connection to the target endpoint, and simply funnel traffic backwards.
Yes Fiddler is an option for me:
Open Fiddler menu > Rules > Customize Rules (this effectively edits CustomRules.js).
Find the function OnBeforeResponse
Add the following lines:
oSession.oResponse.headers.Remove("X-Frame-Options");
oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
Remember to save the script!
As for second question - you can use Fiddler filters to set response X-Frame-Options header manually to something like ALLOW-FROM *. But, of course, this trick will work only for you - other users still won't be able to see iframe content(if they not do the same).